Re: [PATCH] lockdep: lock_set_subclass - reset a held lock's subclass

[Linus Torvalds <torvalds@linux-foundation.org>]

On Fri, 1 Aug 2008, David Miller wrote:
> 
> Taking more than a few locks of the same class at once is bad
> news and it's better to find an alternative method.

It's not always wrong.

If you can guarantee that anybody that takes more than one lock of a 
particular class will always take a single top-level lock _first_, then 
that's all good. You can obviously screw up and take the same lock _twice_ 
(which will deadlock), but at least you cannot get into ABBA situations.

So maybe the right thing to do is to just teach lockdep about "lock 
protection locks". That would have solved the multi-queue issues for 
networking too - all the actual network drivers would still have taken 
just their single queue lock, but the one case that needs to take all of 
them would have taken a separate top-level lock first.

Never mind that the multi-queue locks were always taken in the same order: 
it's never wrong to just have some top-level serialization, and anybody 
who needs to take <n> locks might as well do <n+1>, because they sure as 
hell aren't going to be on _any_ fastpaths.

So the simplest solution really sounds like just teaching lockdep about 
that one special case. It's not "nesting" exactly, although it's obviously 
related to it.

			Linus