12 Jul, 2013
1 commit
-
Oleg Nesterov recently noticed that the lockdep annotations in lglock.c
are not sufficient to detect some obvious deadlocks, such as
lg_local_lock(LOCK) + lg_local_lock(LOCK) or spin_lock(X) +
lg_local_lock(Y) vs lg_local_lock(Y) + spin_lock(X).Both issues are easily fixed by indicating to lockdep that lglock's local
locks are not recursive. We shouldn't use the rwlock acquire/release
functions here, as lglock doesn't share the same semantics. Instead we
can base our lockdep annotations on the lock_acquire_shared (for local
lglock) and lock_acquire_exclusive (for global lglock) helpers.I am not proposing new lglock specific helpers as I don't see the point of
the existing second level of helpers :)Noticed-by: Oleg Nesterov
Signed-off-by: Michel Lespinasse
Cc: Lai Jiangshan
Cc: "Srivatsa S. Bhat"
Cc: Rusty Russell
Cc: Andi Kleen
Cc: "Paul E. McKenney"
Cc: Steven Rostedt
Signed-off-by: Andrew Morton
Signed-off-by: Peter Zijlstra
Link: http://lkml.kernel.org/r/20130708212352.1769031C15E@corp2gmr1-1.hot.corp.google.com
Signed-off-by: Ingo Molnar
30 May, 2012
1 commit
-
lglocks and brlocks are currently generated with some complicated macros
in lglock.h. But there's no reason to not just use common utility
functions and put all the data into a common data structure.Since there are at least two users it makes sense to share this code in a
library. This is also easier maintainable than a macro forest.This will also make it later possible to dynamically allocate lglocks and
also use them in modules (this would both still need some additional, but
now straightforward, code)[akpm@linux-foundation.org: checkpatch fixes]
Signed-off-by: Andi Kleen
Cc: Al Viro
Cc: Rusty Russell
Signed-off-by: Andrew Morton
Signed-off-by: Rusty Russell
Signed-off-by: Al Viro