summaryrefslogtreecommitdiffstats
path: root/kernel/spinlock.c
diff options
context:
space:
mode:
authorPeter Zijlstra2008-08-11 09:30:24 +0200
committerIngo Molnar2008-08-11 09:30:24 +0200
commit7531e2f34d1d551b096143f19111139f0dd84c8b (patch)
tree0a29d6703e28dc6752b9b4085594cca238595aac /kernel/spinlock.c
parentlockdep: map_acquire (diff)
downloadkernel-qcow2-linux-7531e2f34d1d551b096143f19111139f0dd84c8b.tar.gz
kernel-qcow2-linux-7531e2f34d1d551b096143f19111139f0dd84c8b.tar.xz
kernel-qcow2-linux-7531e2f34d1d551b096143f19111139f0dd84c8b.zip
lockdep: lock protection locks
On Fri, 2008-08-01 at 16:26 -0700, Linus Torvalds wrote: > 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. Do as Linus suggested. The lock protection lock is called nest_lock. Note that we still have the MAX_LOCK_DEPTH (48) limit to consider, so anything that spills that it still up shit creek. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'kernel/spinlock.c')
0 files changed, 0 insertions, 0 deletions