linux-kernel - Re: [PATCH] PM / wakeirq: Add wakeup name to dedicated wake irqs

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:   Fri, 16 Feb 2018 16:52:22 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Tony Lindgren <tony@...mide.com>,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Alan Stern <stern@...land.harvard.edu>,
        Linux PM <linux-pm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Brian Norris <briannorris@...omium.org>,
        Grygorii Strashko <grygorii.strashko@...com>,
        Ulf Hansson <ulf.hansson@...aro.org>
Subject: Re: [PATCH] PM / wakeirq: Add wakeup name to dedicated wake irqs

On Fri, Feb 16, 2018 at 12:54 PM, Rafael J. Wysocki <rafael@...nel.org> wrote:
> On Fri, Feb 16, 2018 at 11:39 AM, Andy Shevchenko
> <andy.shevchenko@...il.com> wrote:
>> On Fri, Feb 16, 2018 at 11:14 AM, Rafael J. Wysocki <rafael@...nel.org> wrote:
>>> On Wed, Feb 14, 2018 at 12:23 PM, Andy Shevchenko
>>> <andy.shevchenko@...il.com> wrote:

>>> IMO it is somewhat excessive to put the entire sprintf() under a raw
>>> spinlock and it's not even necessary.
>>
>> It's a copy'n'paste of from the rest of functions there.
>
> Fair enough. :-)

>>> The value can change any time after you've dropped the lock and in
>>> particular before the function returns, so why bother with locking?
>>> desc will not go away from under you at that point anyway.
>>
>> IIRC descriptor's content might be changed, or descriptor itself might
>> be gone (potential crash).
>
> No, desc cannot go away at this point AFAICS due to the kernfs
> refcounting.  And the lock is *inside* of the desc object anyway, so
> it doesn't help really against that.

Oh, indeed.

> The contents may change, but so what?
>
> Effectively, you read an int and reading an int is atomic.  It may
> change after that, but the lock doesn't prevent it from changing.  It
> only prevents the change from being applied to it before you drop the
> lock, but why do you care?

So, with explanations above, perhaps we can produce the patch to
remove those locks from the rest?

-- 
With Best Regards,
Andy Shevchenko