linux-kernel - Re: [PATCH] Input: omap-keypad - fix runtime pm imbalance on error

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:   Wed, 20 May 2020 19:19:05 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     Dinghao Liu <dinghao.liu@....edu.cn>,
        "Rafael J. Wysocki" <rafael@...nel.org>, Kangjie Lu <kjlu@....edu>,
        Richard Fontana <rfontana@...hat.com>,
        Allison Randal <allison@...utok.net>,
        Thomas Gleixner <tglx@...utronix.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Input: omap-keypad - fix runtime pm imbalance on error

On Wed, May 20, 2020 at 7:02 PM Dmitry Torokhov
<dmitry.torokhov@...il.com> wrote:
>
> Hi Dinghao,
>
> On Wed, May 20, 2020 at 6:35 AM Dinghao Liu <dinghao.liu@....edu.cn> wrote:
> >
> > pm_runtime_get_sync() increments the runtime PM usage counter even
> > the call returns an error code. Thus a pairing decrement is needed
> > on the error handling path to keep the counter balanced.
>
> This is a very surprising behavior and I wonder if this should be
> fixed in the PM core (or the required cleanup steps need to be called
> out in the function description).

It has been like that forever and it's intentional, because it allows
certain pieces of code to do things like

pm_runtime_get_sync(dev);
/* do something regardless of whether or not PM-runtime is enabled for dev */
pm_runtime_put(dev);

So I wouldn't really call it surprising.

> I also see that a few drivers that
> handle this situation correctly (?) call pm_runtime_put_noidle()
> instead of pm_runtime_put_sync() in the error path.
>
> Rafael, do you have any guidance here?

Feel free to improve the kerneldoc comment of __pm_runtime_resume(),
although it is clear enough to me, and fix the callers that leak the
refcount.