[PATCH 4/4] kill-the-bkl/reiserfs: panic in case of lock imbalance

From: Frederic Weisbecker
Date: Mon Aug 24 2009 - 22:33:20 EST

Until now, trying to unlock the reiserfs write lock whereas the current
task doesn't hold it lead to a simple warning.
We should actually warn and panic in this case to avoid the user datas
to reach an unstable state.

Signed-off-by: Frederic Weisbecker <fweisbec@xxxxxxxxx>
Cc: Jeff Mahoney <jeffm@xxxxxxxx>
Cc: Chris Mason <chris.mason@xxxxxxxxxx>
Cc: Ingo Molnar <mingo@xxxxxxx>
Cc: Alexander Beregalov <a.beregalov@xxxxxxxxx>
Cc: Laurent Riffard <laurent.riffard@xxxxxxx>
fs/reiserfs/lock.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/fs/reiserfs/lock.c b/fs/reiserfs/lock.c
index cb1bba3..ee2cfc0 100644
--- a/fs/reiserfs/lock.c
+++ b/fs/reiserfs/lock.c
@@ -37,11 +37,10 @@ void reiserfs_write_unlock(struct super_block *s)

* Are we unlocking without even holding the lock?
- * Such a situation could even raise a BUG() if we don't
- * want the data become corrupted
+ * Such a situation must raise a BUG() if we don't want
+ * to corrupt the data.
- WARN_ONCE(sb_i->lock_owner != current,
- "Superblock write lock imbalance");
+ BUG_ON(sb_i->lock_owner != current);

if (--sb_i->lock_depth == -1) {
sb_i->lock_owner = NULL;

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/