summaryrefslogtreecommitdiff
path: root/fs/signalfd.c
diff options
context:
space:
mode:
authorAbhijith Das <adas@redhat.com>2007-11-29 20:13:54 (GMT)
committerSteven Whitehouse <swhiteho@redhat.com>2008-01-25 08:08:18 (GMT)
commit292c8c14cace19c94c6abe25506310239daf949e (patch)
tree3b1b1407e00abc154768dc2f5a684b0fcf0cbd1f /fs/signalfd.c
parentc97bfe4351771675963e02f34d31e206fd2d7150 (diff)
downloadlinux-292c8c14cace19c94c6abe25506310239daf949e.tar.xz
[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/signalfd.c')
0 files changed, 0 insertions, 0 deletions