diff mbox series

[2/3] dmaengine: usb-dmac: Fix PM reference leak in usb_dmac_probe()

Message ID 20210517081826.1564698-3-yukuai3@huawei.com (mailing list archive)
State New
Headers show
Series cleanup patches for PM reference leak | expand

Commit Message

yukuai (C) May 17, 2021, 8:18 a.m. UTC
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
---
 drivers/dma/sh/usb-dmac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Vinod Koul May 31, 2021, 4 a.m. UTC | #1
On 17-05-21, 16:18, Yu Kuai wrote:
> pm_runtime_get_sync will increment pm usage counter even it failed.
> Forgetting to putting operation will result in reference leak here.
> Fix it by replacing it with pm_runtime_resume_and_get to keep usage
> counter balanced.
> 
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: Yu Kuai <yukuai3@huawei.com>
> ---
>  drivers/dma/sh/usb-dmac.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/dma/sh/usb-dmac.c b/drivers/dma/sh/usb-dmac.c
> index 8f7ceb698226..2a6c8fd8854e 100644
> --- a/drivers/dma/sh/usb-dmac.c
> +++ b/drivers/dma/sh/usb-dmac.c
> @@ -796,7 +796,7 @@ static int usb_dmac_probe(struct platform_device *pdev)
>  
>  	/* Enable runtime PM and initialize the device. */
>  	pm_runtime_enable(&pdev->dev);
> -	ret = pm_runtime_get_sync(&pdev->dev);
> +	ret = pm_runtime_resume_and_get(&pdev->dev);

This does not seem to fix anything.. the below goto goes and disables
the runtime_pm for this device and thus there wont be any leak

>  	if (ret < 0) {
>  		dev_err(&pdev->dev, "runtime PM get sync failed (%d)\n", ret);
>  		goto error_pm;
> -- 
> 2.25.4
yukuai (C) May 31, 2021, 6:11 a.m. UTC | #2
On 2021/05/31 12:00, Vinod Koul wrote:
> On 17-05-21, 16:18, Yu Kuai wrote:
>> pm_runtime_get_sync will increment pm usage counter even it failed.
>> Forgetting to putting operation will result in reference leak here.
>> Fix it by replacing it with pm_runtime_resume_and_get to keep usage
>> counter balanced.
>>
>> Reported-by: Hulk Robot <hulkci@huawei.com>
>> Signed-off-by: Yu Kuai <yukuai3@huawei.com>
>> ---
>>   drivers/dma/sh/usb-dmac.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/dma/sh/usb-dmac.c b/drivers/dma/sh/usb-dmac.c
>> index 8f7ceb698226..2a6c8fd8854e 100644
>> --- a/drivers/dma/sh/usb-dmac.c
>> +++ b/drivers/dma/sh/usb-dmac.c
>> @@ -796,7 +796,7 @@ static int usb_dmac_probe(struct platform_device *pdev)
>>   
>>   	/* Enable runtime PM and initialize the device. */
>>   	pm_runtime_enable(&pdev->dev);
>> -	ret = pm_runtime_get_sync(&pdev->dev);
>> +	ret = pm_runtime_resume_and_get(&pdev->dev);
> 
> This does not seem to fix anything.. the below goto goes and disables
> the runtime_pm for this device and thus there wont be any leak
Hi,

If pm_runtime_get_sync() fails and increments the pm.usage_count
variable, pm_runtime_disable() does not reset the counter, and
we still need to decrement the usage count when pm_runtime_get_sync()
fails. Do I miss anthing?

Thansk!
Yu Kuai
> 
>>   	if (ret < 0) {
>>   		dev_err(&pdev->dev, "runtime PM get sync failed (%d)\n", ret);
>>   		goto error_pm;
>> -- 
>> 2.25.4
>
Vinod Koul May 31, 2021, 8:57 a.m. UTC | #3
On 31-05-21, 14:11, yukuai (C) wrote:
> On 2021/05/31 12:00, Vinod Koul wrote:
> > On 17-05-21, 16:18, Yu Kuai wrote:
> > > pm_runtime_get_sync will increment pm usage counter even it failed.
> > > Forgetting to putting operation will result in reference leak here.
> > > Fix it by replacing it with pm_runtime_resume_and_get to keep usage
> > > counter balanced.
> > > 
> > > Reported-by: Hulk Robot <hulkci@huawei.com>
> > > Signed-off-by: Yu Kuai <yukuai3@huawei.com>
> > > ---
> > >   drivers/dma/sh/usb-dmac.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/dma/sh/usb-dmac.c b/drivers/dma/sh/usb-dmac.c
> > > index 8f7ceb698226..2a6c8fd8854e 100644
> > > --- a/drivers/dma/sh/usb-dmac.c
> > > +++ b/drivers/dma/sh/usb-dmac.c
> > > @@ -796,7 +796,7 @@ static int usb_dmac_probe(struct platform_device *pdev)
> > >   	/* Enable runtime PM and initialize the device. */
> > >   	pm_runtime_enable(&pdev->dev);
> > > -	ret = pm_runtime_get_sync(&pdev->dev);
> > > +	ret = pm_runtime_resume_and_get(&pdev->dev);
> > 
> > This does not seem to fix anything.. the below goto goes and disables
> > the runtime_pm for this device and thus there wont be any leak
> Hi,
> 
> If pm_runtime_get_sync() fails and increments the pm.usage_count
> variable, pm_runtime_disable() does not reset the counter, and
> we still need to decrement the usage count when pm_runtime_get_sync()
> fails. Do I miss anthing?

Yes the rumtime_pm is disabled on failure here and the count would have
no consequence...
Johan Hovold May 31, 2021, 9:19 a.m. UTC | #4
On Mon, May 31, 2021 at 02:27:34PM +0530, Vinod Koul wrote:
> On 31-05-21, 14:11, yukuai (C) wrote:
> > On 2021/05/31 12:00, Vinod Koul wrote:
> > > On 17-05-21, 16:18, Yu Kuai wrote:
> > > > pm_runtime_get_sync will increment pm usage counter even it failed.
> > > > Forgetting to putting operation will result in reference leak here.
> > > > Fix it by replacing it with pm_runtime_resume_and_get to keep usage
> > > > counter balanced.
> > > > 
> > > > Reported-by: Hulk Robot <hulkci@huawei.com>
> > > > Signed-off-by: Yu Kuai <yukuai3@huawei.com>
> > > > ---
> > > >   drivers/dma/sh/usb-dmac.c | 2 +-
> > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/dma/sh/usb-dmac.c b/drivers/dma/sh/usb-dmac.c
> > > > index 8f7ceb698226..2a6c8fd8854e 100644
> > > > --- a/drivers/dma/sh/usb-dmac.c
> > > > +++ b/drivers/dma/sh/usb-dmac.c
> > > > @@ -796,7 +796,7 @@ static int usb_dmac_probe(struct platform_device *pdev)
> > > >   	/* Enable runtime PM and initialize the device. */
> > > >   	pm_runtime_enable(&pdev->dev);
> > > > -	ret = pm_runtime_get_sync(&pdev->dev);
> > > > +	ret = pm_runtime_resume_and_get(&pdev->dev);
> > > 
> > > This does not seem to fix anything.. the below goto goes and disables
> > > the runtime_pm for this device and thus there wont be any leak
> > Hi,
> > 
> > If pm_runtime_get_sync() fails and increments the pm.usage_count
> > variable, pm_runtime_disable() does not reset the counter, and
> > we still need to decrement the usage count when pm_runtime_get_sync()
> > fails. Do I miss anthing?
> 
> Yes the rumtime_pm is disabled on failure here and the count would have
> no consequence...

You should still balance the PM usage counter as it isn't reset for
example when reloading the driver.

Using pm_runtime_resume_and_get() is one way of handling this, but
alternatively you could also move the error_pm label above the
pm_runtime_put() in the error path.

Johan
Vinod Koul June 3, 2021, 11:09 a.m. UTC | #5
On 31-05-21, 11:19, Johan Hovold wrote:
> On Mon, May 31, 2021 at 02:27:34PM +0530, Vinod Koul wrote:
> > On 31-05-21, 14:11, yukuai (C) wrote:
> > > On 2021/05/31 12:00, Vinod Koul wrote:
> > > > On 17-05-21, 16:18, Yu Kuai wrote:
> > > > > pm_runtime_get_sync will increment pm usage counter even it failed.
> > > > > Forgetting to putting operation will result in reference leak here.
> > > > > Fix it by replacing it with pm_runtime_resume_and_get to keep usage
> > > > > counter balanced.
> > > > > 
> > > > > Reported-by: Hulk Robot <hulkci@huawei.com>
> > > > > Signed-off-by: Yu Kuai <yukuai3@huawei.com>
> > > > > ---
> > > > >   drivers/dma/sh/usb-dmac.c | 2 +-
> > > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/dma/sh/usb-dmac.c b/drivers/dma/sh/usb-dmac.c
> > > > > index 8f7ceb698226..2a6c8fd8854e 100644
> > > > > --- a/drivers/dma/sh/usb-dmac.c
> > > > > +++ b/drivers/dma/sh/usb-dmac.c
> > > > > @@ -796,7 +796,7 @@ static int usb_dmac_probe(struct platform_device *pdev)
> > > > >   	/* Enable runtime PM and initialize the device. */
> > > > >   	pm_runtime_enable(&pdev->dev);
> > > > > -	ret = pm_runtime_get_sync(&pdev->dev);
> > > > > +	ret = pm_runtime_resume_and_get(&pdev->dev);
> > > > 
> > > > This does not seem to fix anything.. the below goto goes and disables
> > > > the runtime_pm for this device and thus there wont be any leak
> > > Hi,
> > > 
> > > If pm_runtime_get_sync() fails and increments the pm.usage_count
> > > variable, pm_runtime_disable() does not reset the counter, and
> > > we still need to decrement the usage count when pm_runtime_get_sync()
> > > fails. Do I miss anthing?
> > 
> > Yes the rumtime_pm is disabled on failure here and the count would have
> > no consequence...
> 
> You should still balance the PM usage counter as it isn't reset for
> example when reloading the driver.

Should I driver trust that on load PM usage counter is balanced and not
to be reset..?

> Using pm_runtime_resume_and_get() is one way of handling this, but
> alternatively you could also move the error_pm label above the
> pm_runtime_put() in the error path.

That would be a better way I think
Johan Hovold June 7, 2021, 8:06 a.m. UTC | #6
On Thu, Jun 03, 2021 at 04:39:08PM +0530, Vinod Koul wrote:
> On 31-05-21, 11:19, Johan Hovold wrote:
> > On Mon, May 31, 2021 at 02:27:34PM +0530, Vinod Koul wrote:
> > > On 31-05-21, 14:11, yukuai (C) wrote:
> > > > On 2021/05/31 12:00, Vinod Koul wrote:
> > > > > On 17-05-21, 16:18, Yu Kuai wrote:
> > > > > > pm_runtime_get_sync will increment pm usage counter even it failed.
> > > > > > Forgetting to putting operation will result in reference leak here.
> > > > > > Fix it by replacing it with pm_runtime_resume_and_get to keep usage
> > > > > > counter balanced.

> > > Yes the rumtime_pm is disabled on failure here and the count would have
> > > no consequence...
> > 
> > You should still balance the PM usage counter as it isn't reset for
> > example when reloading the driver.
> 
> Should I driver trust that on load PM usage counter is balanced and not
> to be reset..?

Not sure what you're asking here. But a driver should never leave the PM
usage counter unbalanced.

> > Using pm_runtime_resume_and_get() is one way of handling this, but
> > alternatively you could also move the error_pm label above the
> > pm_runtime_put() in the error path.
> 
> That would be a better way I think

Johan
Vinod Koul June 7, 2021, 10:19 a.m. UTC | #7
On 07-06-21, 10:06, Johan Hovold wrote:
> On Thu, Jun 03, 2021 at 04:39:08PM +0530, Vinod Koul wrote:
> > On 31-05-21, 11:19, Johan Hovold wrote:
> > > On Mon, May 31, 2021 at 02:27:34PM +0530, Vinod Koul wrote:
> > > > On 31-05-21, 14:11, yukuai (C) wrote:
> > > > > On 2021/05/31 12:00, Vinod Koul wrote:
> > > > > > On 17-05-21, 16:18, Yu Kuai wrote:
> > > > > > > pm_runtime_get_sync will increment pm usage counter even it failed.
> > > > > > > Forgetting to putting operation will result in reference leak here.
> > > > > > > Fix it by replacing it with pm_runtime_resume_and_get to keep usage
> > > > > > > counter balanced.
> 
> > > > Yes the rumtime_pm is disabled on failure here and the count would have
> > > > no consequence...
> > > 
> > > You should still balance the PM usage counter as it isn't reset for
> > > example when reloading the driver.
> > 
> > Should I driver trust that on load PM usage counter is balanced and not
> > to be reset..?
> 
> Not sure what you're asking here. But a driver should never leave the PM
> usage counter unbalanced.

Thinking about again, yes we should safely assume the counter is
balanced when driver loads.. so unloading while balancing sounds better
behaviour

Thanks
diff mbox series

Patch

diff --git a/drivers/dma/sh/usb-dmac.c b/drivers/dma/sh/usb-dmac.c
index 8f7ceb698226..2a6c8fd8854e 100644
--- a/drivers/dma/sh/usb-dmac.c
+++ b/drivers/dma/sh/usb-dmac.c
@@ -796,7 +796,7 @@  static int usb_dmac_probe(struct platform_device *pdev)
 
 	/* Enable runtime PM and initialize the device. */
 	pm_runtime_enable(&pdev->dev);
-	ret = pm_runtime_get_sync(&pdev->dev);
+	ret = pm_runtime_resume_and_get(&pdev->dev);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "runtime PM get sync failed (%d)\n", ret);
 		goto error_pm;