Messages in this thread | | | Date | Wed, 25 Apr 2012 14:59:36 -0700 | From | Tejun Heo <> | Subject | Re: Lockdep false positive in sysfs |
| |
Hello, Alan.
On Wed, Apr 25, 2012 at 02:58:28PM -0400, Alan Stern wrote: > Peter and Tejun: > > Here's my problem, which affects several sysfs attribute methods in the > USB subsystem: > > Sysfs attribute A is attached to a USB device D. When the user writes > to A, the corresponding store method unregisters D's children (it does > not unregister D, though). > > Now, some of these children may also be USB devices (i.e., if D is a > hub), and therefore may have the same set of sysfs attributes. As a > result, A's store method for D will end up removing the A attribute for > device E, where E is a child of D. > > This causes lockdep to complain. When A's method is called, sysfs > tells lockdep that it holds a readlock for the s_active "rwsem" > associated with the A attribute for D. However the sysfs routine that > removes attributes tells lockdep that it is going to get a writelock > for the s_active associated with the A attribute for E, which is in the > same lockdep class since it belongs to the same attribute.
Hmmm.... This happens because, by default, sysfs_dirents for the same attr share the same lockdep key. This happens from sysfs_dirent_init_lockdep(). Hmm.... we can,
* Somehow assign different keys to sysfs_dirents for the specific attr. Use array of attrs indexed by bus depth?
* Add a flag / whatever to attr indicating that the files of the attribute may be removed recursively (lockdep-wise) and update either read or write path to use subclass.
Any better ideas?
Thanks.
-- tejun
| |