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

From: Alan Stern
Date: Fri Aug 07 2009 - 12:45:46 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/