linux-kernel - Re: [RT] Lockdep warning on boot with 2.6.31-rc5-rt1.1

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 7 Aug 2009 12:45:37 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Clark Williams <williams@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	RT <linux-rt-users@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"greg@...ah.com" <greg@...ah.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Kay Sievers <kay.sievers@...y.org>
Subject: Re: [RT] Lockdep warning on boot with 2.6.31-rc5-rt1.1

On Fri, 7 Aug 2009, Peter Zijlstra wrote:

> > I think they are, pretty much.  The real problem, of course, is that 
> > lockdep doesn't understand tree-structured lock orderings.  Hence it 
> > isn't practical to convert dev->sem into a mutex.
> 
> Right, well it would if we'd make every instance a class, but since
> classes should reside in static storage this is far from trivial.
> 
> If we'd be able to find a mapping such that we can use a limited number
> of these classes to represent the needed structure then we're good.
> 
> I think I proposed adding a class to each driver or something, but then
> you countered that a single driver could register itself at conflicting
> places in the device tree.

Also there can be devices in the tree that don't have any driver.  And 
there can be devices that have the same driver as their children.

> Still it might be worth to try that and see where we'll end up and
> possibly fix up a few drivers to be more intelligent.
> 
> /me ponders
> 
> Nested busses would be interesting though, suppose we assign a class to
> a USB bus driver, and we chain USB hubs, you'd get a nesting of similar
> classes and that'd upset lockdep again :/

Yep.

> The other proposal was creating a fixed list of classes and register
> each device at a class corresponding to its depth in the tree. I can't
> remember what was wrong with that, but I seem to have been persuaded
> that that was hard too.

It probably would work for the most part.  However a possible scenario
involves first locking a parent and then locking all its children.  (I
don't know if this ever happens anywhere, but it might.)  This can't
cause a deadlock but it would run into trouble with depth-based
classes.

Alan Stern

--
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/