Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: [PATCH] PM / wakeirq: Add wakeup name to dedicated wake irqs | Date | Tue, 20 Feb 2018 12:14:58 +0100 |
| |
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. :-)
| |