diff options
| author | Frederic Weisbecker <fweisbec@gmail.com> | 2009-08-25 04:18:06 +0200 |
|---|---|---|
| committer | Frederic Weisbecker <fweisbec@gmail.com> | 2009-09-14 07:18:30 +0200 |
| commit | 80503185989b2dd84170bb842e23d3fd45ebdf40 (patch) | |
| tree | 5b1a862071199421ba0427137067b8ed14a0c843 | |
| parent | 7e94277050e31aa4204060f03953bba72598cf7d (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>
| -rw-r--r-- | 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 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) /* * 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; |