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

From: Linus Torvalds
Date: Fri Aug 01 2008 - 19:27:41 EST




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