diff options
author | Peter Zijlstra <peterz@infradead.org> | 2015-06-11 15:46:53 +0300 |
---|---|---|
committer | Thomas Gleixner <tglx@linutronix.de> | 2015-06-19 01:25:27 +0300 |
commit | a24fc60d63da2b0b31bf7c876d12a51ed4b778bd (patch) | |
tree | 8f18a0b885a75b45b22b6f0b6b94abc3b8fab01d /net/irda/af_irda.c | |
parent | e0f56fd7066f35ae3765d080e036fa676a9d4128 (diff) | |
download | linux-a24fc60d63da2b0b31bf7c876d12a51ed4b778bd.tar.xz |
lockdep: Implement lock pinning
Add a lockdep annotation that WARNs if you 'accidentially' unlock a
lock.
This is especially helpful for code with callbacks, where the upper
layer assumes a lock remains taken but a lower layer thinks it maybe
can drop and reacquire the lock.
By unwittingly breaking up the lock, races can be introduced.
Lock pinning is a lockdep annotation that helps with this, when you
lockdep_pin_lock() a held lock, any unlock without a
lockdep_unpin_lock() will produce a WARN. Think of this as a relative
of lockdep_assert_held(), except you don't only assert its held now,
but ensure it stays held until you release your assertion.
RFC: a possible alternative API would be something like:
int cookie = lockdep_pin_lock(&foo);
...
lockdep_unpin_lock(&foo, cookie);
Where we pick a random number for the pin_count; this makes it
impossible to sneak a lock break in without also passing the right
cookie along.
I've not done this because it ends up generating code for !LOCKDEP,
esp. if you need to pass the cookie around for some reason.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: ktkhai@parallels.com
Cc: rostedt@goodmis.org
Cc: juri.lelli@gmail.com
Cc: pang.xunlei@linaro.org
Cc: oleg@redhat.com
Cc: wanpeng.li@linux.intel.com
Cc: umgwanakikbuti@gmail.com
Link: http://lkml.kernel.org/r/20150611124743.906731065@infradead.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Diffstat (limited to 'net/irda/af_irda.c')
0 files changed, 0 insertions, 0 deletions