| Message ID | 20210517081826.1564698-3-yukuai3@huawei.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | cleanup patches for PM reference leak | expand |
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
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 >
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...
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
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
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
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
Hi, Vinod Are you still intrested in accepting this patch? Thanks, Yu Kuai On 2021/06/07 18:19, Vinod Koul wrote: > 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 >
On 05-07-21, 16:41, yukuai (C) wrote: > Hi, Vinod > > Are you still intrested in accepting this patch? - Please do not top post - yes, pls rebase and resend > On 2021/06/07 18:19, Vinod Koul wrote: > > 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 --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;
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(-)