diff options
| author | Abhijith Das <adas@redhat.com> | 2007-11-29 14:13:54 -0600 |
|---|---|---|
| committer | Steven Whitehouse <swhiteho@redhat.com> | 2008-01-25 08:08:18 +0000 |
| commit | 292c8c14cace19c94c6abe25506310239daf949e (patch) | |
| tree | 3b1b1407e00abc154768dc2f5a684b0fcf0cbd1f /fs/cramfs | |
| parent | c97bfe4351771675963e02f34d31e206fd2d7150 (diff) | |
| download | kernel_samsung_smdk4412-292c8c14cace19c94c6abe25506310239daf949e.zip kernel_samsung_smdk4412-292c8c14cace19c94c6abe25506310239daf949e.tar.gz kernel_samsung_smdk4412-292c8c14cace19c94c6abe25506310239daf949e.tar.bz2 | |
[GFS2] patch to check for recursive lock requests in gfs2_rename code path
A certain scenario in the rename code path triggers a kernel BUG()
because it accidentally does recursive locking The first lock is
requested to unlink an already existing inode (replacing a file) and the
second lock is requested when the destination directory needs to alloc
some space. It is rare that these two
events happen during the same rename call, and even more rare that these
two instances try to lock the same rgrp. It is, however, possible.
https://bugzilla.redhat.com/show_bug.cgi?id=404711
Signed-off-by: Abhijith Das <adas@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Diffstat (limited to 'fs/cramfs')
0 files changed, 0 insertions, 0 deletions