On Wed, 2007-10-24 at 14:57 -0700, Greg KH wrote:
> On Wed, Oct 24, 2007 at 10:40:20AM +0200, Johannes Berg wrote:
> > On Wed, 2007-10-24 at 00:18 +0200, Rafael J. Wysocki wrote:
> >
> > > Yes, which is what I think is happening in this particular case. More
> > > precisely, we get pm_mutex while holding a buffer mutex, so lockdep is warning
> > > when we get another buffer mutex afterwards.
> >
> > Precisely. That's why I copied Greg on the second mail :) It seems that
> > sysfs already uses nested locks, but that only protects against lockdep
> > reporting a false positive for nested locks, not this case.
>
> Ok, I'm confused, where is the sysfs issue here?
We have two paths here:
(a) sysfs write -> lock buffer -> call power management code
-> lock pm_mutex
(b) boot code -> power management boot -> lock pm_mutex
-> use name_to_dev_t() -> call sysfs -> lock buffer
As you can see, lockdep rightfully complains about a possible deadlock
scenario although of course (b) only happens once at boot at a time
where (a) cannot happen. And now we're wondering how to fix it.
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
