linux-kernel - Re: [PATCH 09/46] dmaengine: cppi41: use dmaenginem_async_device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 7 Aug 2018 10:01:47 +0300
From:   Peter Ujfalusi <peter.ujfalusi@...com>
To:     Huang Shijie <sjhuang@...vatar.ai>,
        Alexandre Bailon <abailon@...libre.com>,
        Tony Lindgren <tony@...mide.com>
CC:     <vkoul@...nel.org>, <dmaengine@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <dave.jiang@...el.com>,
        <radhey.shyam.pandey@...inx.com>, <appana.durga.rao@...inx.com>,
        <jmkrzyszt@...il.com>, <gomonovych@...il.com>,
        <keescook@...omium.org>, <horms+renesas@...ge.net.au>,
        <geert+renesas@...der.be>, <shawnguo@...nel.org>,
        <baoyou.xie@...aro.org>, <michal.simek@...inx.com>,
        <baohua@...nel.org>, <ludovic.desroches@...rochip.com>,
        <linus.walleij@...aro.org>, <david.brown@...aro.org>
Subject: Re: [PATCH 09/46] dmaengine: cppi41: use
 dmaenginem_async_device_register to simplify the code

Hi,

On 2018-08-06 06:28, Huang Shijie wrote:
> On Fri, Aug 03, 2018 at 10:55:25AM +0300, Peter Ujfalusi wrote:
>>
>>
>> On 2018-08-03 10:19, Huang Shijie wrote:
>>> Use dmaenginem_async_device_register to simplify the code:
>>>    remove dma_async_device_unregister
>>>
>>> Signed-off-by: Huang Shijie <sjhuang@...vatar.ai>
>>> ---
>>>  drivers/dma/ti/cppi41.c | 7 ++-----
>>>  1 file changed, 2 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/dma/ti/cppi41.c b/drivers/dma/ti/cppi41.c
>>> index 1497da367710..d2998a19ed2e 100644
>>> --- a/drivers/dma/ti/cppi41.c
>>> +++ b/drivers/dma/ti/cppi41.c
>>> @@ -1096,21 +1096,19 @@ static int cppi41_dma_probe(struct platform_device *pdev)
>>>  		goto err_chans;
>>>  	cdd->irq = irq;
>>>  
>>> -	ret = dma_async_device_register(&cdd->ddev);
>>> +	ret = dmaenginem_async_device_register(&cdd->ddev);
>>>  	if (ret)
>>>  		goto err_chans;
>>>  
>>>  	ret = of_dma_controller_register(dev->of_node,
>>>  			cppi41_dma_xlate, &cpp41_dma_info);
>>>  	if (ret)
>>> -		goto err_of;
>>> +		goto err_chans;
>>>  
>>>  	pm_runtime_mark_last_busy(dev);
>>>  	pm_runtime_put_autosuspend(dev);
>>>  
>>>  	return 0;
>>> -err_of:
>>> -	dma_async_device_unregister(&cdd->ddev);
>>>  err_chans:
>>>  	deinit_cppi41(dev, cdd);
>>>  err_init_cppi:
>>> @@ -1132,7 +1130,6 @@ static int cppi41_dma_remove(struct platform_device *pdev)
>>>  		dev_err(&pdev->dev, "%s could not pm_runtime_get: %i\n",
>>>  			__func__, error);
>>>  	of_dma_controller_free(pdev->dev.of_node);
>>> -	dma_async_device_unregister(&cdd->ddev);
>>
>> If I read the code right then this is not safe.
> I read the code again, and find it is okay.
> 
>> We would have deinitalized cppi41 driver which is not functional, but we
>> will still have the dma device registered and if a channel is requested
>> we will have kernel crash.
> We cannot succeed to request a channel when the drv->remove() is called.
> 
> Please see __device_release_driver:
>   ---------------------------------------------------------------------
> 		if (dev->bus && dev->bus->remove)
> 			dev->bus->remove(dev);
> 		else if (drv->remove)
> 			drv->remove(dev);
> 
> 		device_links_driver_cleanup(dev);
> 		dma_deconfigure(dev);
> 
> 		devres_release_all(dev);    ============> Devres release
>   ---------------------------------------------------------------------
> 
> For the DMA engine driver, there is only one case which will calls drv->remove():
>         Use the rmmod(or modprobe -r).
> 
> We do not use the device_link_add API for DMA engines.
> And we not manually call the device_release_driver() for DMA engines.
> 
> But when we use the rmmod, the module state will be MODULE_STATE_GOING.
> In the find_candidate(), dma_chan_get() will fail.
> And we cannot get a channel.
> 
> Please correct me if I am wrong :)

You are perfectly right.

It might be only me, but I like to keep the resource teardown in a
reverse order of their creation. If everything is devm then it is granted.

In case of cppi4 it looks safe after reading in to the DMAengine core,
module core and platform core code.

But does the removed three lines worth over the clarity of how the
module removal is proceeding?

Alexandre and Tony put lots of effort to the cppi4 driver, I let them
decide.

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki