netdev - Re: [PATCH v3 1/2] PM: runtime: Add pm_runtime_resume_and

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Mon, 30 Nov 2020 19:35:23 +0200
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Zhang Qilong <zhangqilong3@...wei.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Fugang Duan <fugang.duan@....com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Linux PM list <linux-pm@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Wolfram Sang <wsa+renesas@...g-engineering.com>,
        Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>,
        Ulf Hansson <ulf.hansson@...aro.org>
Subject: Re: [PATCH v3 1/2] PM: runtime: Add pm_runtime_resume_and_get to
 deal with usage counter

On Mon, Nov 30, 2020 at 05:37:52PM +0100, Rafael J. Wysocki wrote:
> On Fri, Nov 27, 2020 at 11:16 AM Geert Uytterhoeven wrote:
> > On Tue, Nov 10, 2020 at 10:29 AM Zhang Qilong <zhangqilong3@...wei.com> wrote:
> > > In many case, we need to check return value of pm_runtime_get_sync, but
> > > it brings a trouble to the usage counter processing. Many callers forget
> > > to decrease the usage counter when it failed, which could resulted in
> > > reference leak. It has been discussed a lot[0][1]. So we add a function
> > > to deal with the usage counter for better coding.
> > >
> > > [0]https://lkml.org/lkml/2020/6/14/88
> > > [1]https://patchwork.ozlabs.org/project/linux-tegra/list/?series=178139
> > > Signed-off-by: Zhang Qilong <zhangqilong3@...wei.com>
> >
> > Thanks for your patch, which is now commit dd8088d5a8969dc2 ("PM:
> > runtime: Add pm_runtime_resume_and_get to deal with usage counter") in
> > v5.10-rc5.
> >
> > > --- a/include/linux/pm_runtime.h
> > > +++ b/include/linux/pm_runtime.h
> > > @@ -386,6 +386,27 @@ static inline int pm_runtime_get_sync(struct device *dev)
> > >         return __pm_runtime_resume(dev, RPM_GET_PUT);
> > >  }
> > >
> > > +/**
> > > + * pm_runtime_resume_and_get - Bump up usage counter of a device and resume it.
> > > + * @dev: Target device.
> > > + *
> > > + * Resume @dev synchronously and if that is successful, increment its runtime
> > > + * PM usage counter. Return 0 if the runtime PM usage counter of @dev has been
> > > + * incremented or a negative error code otherwise.
> > > + */
> > > +static inline int pm_runtime_resume_and_get(struct device *dev)
> >
> > Perhaps this function should be called pm_runtime_resume_and_get_sync(),
> 
> No, really.
> 
> I might consider calling it pm_runtime_acquire(), and adding a
> matching _release() as a pm_runtime_get() synonym for that matter, but
> not the above.

pm_runtime_acquire() seems better to me too. Would pm_runtime_release()
would be an alias for pm_runtime_put() ?

We would also likely need a pm_runtime_release_autosuspend() too then.
But on that topic, I was wondering, is there a reason we can't select
autosuspend behaviour automatically when autosuspend is enabled ?

> > to make it clear it does a synchronous get?
> >
> > I had to look into the implementation to verify that a change like
> 
> I'm not sure why, because the kerneldoc is unambiguous AFAICS.
> 
> >
> > -       ret = pm_runtime_get_sync(&pdev->dev);
> > +       ret = pm_runtime_resume_and_get(&pdev->dev);
> >
> > in the follow-up patches is actually a valid change, maintaining
> > synchronous operation. Oh, pm_runtime_resume() is synchronous, too...
> 
> Yes, it is.

-- 
Regards,

Laurent Pinchart