> lockdep would be right to moan about that -- if you have two tasks
> trying to do that, they can deadlock against each other.
There you go -- you are suffering the same weakness as lockdep. It's not possible for two
tasks to deadlock when acquiring locks in a tree structure provided that the locks are always
acquired going down a branch. (Or if the locks are always acquired going up a branch.) This
sort of constraint could potentially be represented within lockdep, but right now there's no
way to do it.
> The real problem with lockdep is that mutexes have an owner and
> semaphores simply don't.
That isn't a problem with lockdep; it's a problem with trying to use lockdep to track general
semaphore usage. Lack of explicit parents for semaphores hasn't prevented many semaphores
from being converted to mutexes, complete with lockdep monitoring.
My point was that even though a semaphore may be used for simple mutual exclusion in a way
that should be compatible with replacement by a mutex, the replacement can't be carried out if
the semaphore is being used to lock members of a tree.