On 31-05-21, 11:19, Johan Hovold wrote:

On Mon, May 31, 2021 at 02:27:34PM +0530, Vinod Koul wrote:

quoted

On 31-05-21, 14:11, yukuai (C) wrote:

quoted

On 2021/05/31 12:00, Vinod Koul wrote:

quoted

On 17-05-21, 16:18, Yu Kuai wrote:

quoted

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 <redacted>
Signed-off-by: Yu Kuai <redacted>
---
  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

-- 
~Vinod