From: Tejun Heo <tj@kernel.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Peter Zijlstra <peterz@infradead.org>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: Lockdep false positive in sysfs
Date: Wed, 25 Apr 2012 14:59:36 -0700 [thread overview]
Message-ID: <20120425215936.GC8989@google.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1204251436140.1206-100000@iolanthe.rowland.org>
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
next prev parent reply other threads:[~2012-04-25 21:59 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-25 18:58 Lockdep false positive in sysfs Alan Stern
2012-04-25 21:59 ` Tejun Heo [this message]
2012-04-26 8:16 ` Eric W. Biederman
2012-04-26 18:14 ` Alan Stern
2012-04-26 22:17 ` Tejun Heo
2012-04-27 15:57 ` Alan Stern
2012-04-27 16:09 ` Tejun Heo
2012-05-03 21:30 ` Alan Stern
2012-05-04 16:52 ` Tejun Heo
2012-05-04 19:08 ` Alan Stern
2012-05-07 19:46 ` Tejun Heo
2012-05-07 21:51 ` Alan Stern
2012-05-07 21:55 ` Tejun Heo
2012-05-08 18:53 ` Alan Stern
2012-05-09 17:41 ` Tejun Heo
2012-05-09 17:47 ` Alan Stern
2012-05-09 17:48 ` Tejun Heo
2012-04-27 16:27 ` Eric W. Biederman
2012-04-27 18:27 ` Alan Stern
2012-04-27 20:17 ` Tejun Heo
2012-04-27 21:09 ` Eric W. Biederman
2012-04-27 21:16 ` Tejun Heo
2012-04-29 2:00 ` Alan Stern
2012-04-29 2:35 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120425215936.GC8989@google.com \
--to=tj@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.