lkml.org 
[lkml]   [2018]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] PM / wakeirq: Add wakeup name to dedicated wake irqs
Date
On Friday, February 16, 2018 3:52:22 PM CET Andy Shevchenko wrote:
> On Fri, Feb 16, 2018 at 12:54 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > On Fri, Feb 16, 2018 at 11:39 AM, Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
> >> On Fri, Feb 16, 2018 at 11:14 AM, Rafael J. Wysocki <rafael@kernel.org> wrote:
> >>> On Wed, Feb 14, 2018 at 12:23 PM, Andy Shevchenko
> >>> <andy.shevchenko@gmail.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?

Well, I guess so.

I'm not the maintainer of that code, however. :-)

\
 
 \ /
  Last update: 2018-02-20 12:18    [W:0.046 / U:0.852 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site