linux-kernel - Re: Lockdep false positive in sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 28 Apr 2012 19:35:32 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Tejun Heo <tj@...nel.org>, Peter Zijlstra <peterz@...radead.org>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Lockdep false positive in sysfs

Alan Stern <stern@...land.harvard.edu> writes:

> On Fri, 27 Apr 2012, Eric W. Biederman wrote:
>
>> However it would be nice if we could sort out the locking so that it
>> isn't so tricky that neither lockdep nor sparse can figure it out.
>> 
>> I have the sneaking suspicion that idioms that tangle up our automatic
>> tools are also idioms that are likely to result in maintenance problems
>> at some point.
>
> That may well be true, but it won't be easy to avoid them.  At the
> least, it would require a careful analysis of the device tree usage.
>
>> Another possibility to to look at the situation and realize that pci has
>> a maxium depth of 256 (bus numbers). And that usb also has a maxium
>> depth of I believe 256 ( If I read it right usb hubs are transparent to
>> usb enumeration so the maximum depth is the maximum number of usb ids
>> and I think the usb id is a 8 bit number).
>
> USB has a maximum depth of 7 or so.  It's limited by the number of hubs 
> allowed on the path between the host and a device.
>
>>  I don't think anything else
>> even nests so deeply.  So it may be reasonable to declare an array of
>> 256 or perhaps 1024 lockdep keys and limit the device tree when lockdep
>> is enabled to 1024 layers deep.
>> 
>> At which point we are at a point where lockdep can actually analyze the
>> behavior.
>
> Unfortunately, we are not.  As I mentioned earlier, the device "tree" 
> is really a forest.  Locks are sometimes acquired in orders that are 
> not strictly downward.

Then it sounds like for the device tree in general this is a limitation.
For sysfs with your problem usb attribute this looks like a real
solution.

>> I don't mind the attitude we are clever careful programmers we can
>> handle the complexity and we can get away without the tool help us, but
>> I would much rather see the attitude that we are clever careful
>> programmers and we can figure out how to make the tool help us instead
>> of just ignoring it.
>
> I'm certainly open to suggestions as to how to improve the situation, 
> but the simple-minded "keep track of the depth in the tree" approach 
> doesn't work.

For the general device tree perhaps.  For the problem of your removal
of your sysfs attribute the solution should be sufficient.  I don't
particularly like it because it will take a lot of testing to find any
bugs that lockdep might reveal but at least you will have a fighting
chance.

I would like to look at the general problem of the device tree locking.
Unfortunately I am tilting at enough other windmills right now that I
can't do that problem justice.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/