aboutsummaryrefslogtreecommitdiffstats
path: root/fs
diff options
context:
space:
mode:
authorFrederic Weisbecker <fweisbec@gmail.com>2009-08-24 22:18:06 -0400
committerFrederic Weisbecker <fweisbec@gmail.com>2009-09-14 01:18:30 -0400
commit80503185989b2dd84170bb842e23d3fd45ebdf40 (patch)
tree5b1a862071199421ba0427137067b8ed14a0c843 /fs
parent7e94277050e31aa4204060f03953bba72598cf7d (diff)
kill-the-bkl/reiserfs: panic in case of lock imbalance
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@gmail.com> Cc: Jeff Mahoney <jeffm@suse.com> Cc: Chris Mason <chris.mason@oracle.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Alexander Beregalov <a.beregalov@gmail.com> Cc: Laurent Riffard <laurent.riffard@free.fr>
Diffstat (limited to 'fs')
-rw-r--r--fs/reiserfs/lock.c7
1 files changed, 3 insertions, 4 deletions
diff --git a/fs/reiserfs/lock.c b/fs/reiserfs/lock.c
index cb1bba3802dd..ee2cfc0fd8a7 100644
--- a/fs/reiserfs/lock.c
+++ b/fs/reiserfs/lock.c
@@ -37,11 +37,10 @@ void reiserfs_write_unlock(struct super_block *s)
37 37
38 /* 38 /*
39 * Are we unlocking without even holding the lock? 39 * Are we unlocking without even holding the lock?
40 * Such a situation could even raise a BUG() if we don't 40 * Such a situation must raise a BUG() if we don't want
41 * want the data become corrupted 41 * to corrupt the data.
42 */ 42 */
43 WARN_ONCE(sb_i->lock_owner != current, 43 BUG_ON(sb_i->lock_owner != current);
44 "Superblock write lock imbalance");
45 44
46 if (--sb_i->lock_depth == -1) { 45 if (--sb_i->lock_depth == -1) {
47 sb_i->lock_owner = NULL; 46 sb_i->lock_owner = NULL;