linux-kernel - Re: [PATCH] lockdep: lock_set_subclass

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <alpine.LFD.1.10.0808011623040.6819@nehalem.linux-foundation.org>
Date:	Fri, 1 Aug 2008 16:26:56 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Miller <davem@...emloft.net>
cc:	hugh@...itas.com, jeremy@...p.org, a.p.zijlstra@...llo.nl,
	mingo@...e.hu, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org
Subject: Re: [PATCH] lockdep: lock_set_subclass - reset a held lock's
 subclass

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