GFS2: Fix deadlock on journal flush
authorSteven Whitehouse <swhiteho@redhat.com>
Thu, 5 Feb 2009 10:12:38 +0000 (10:12 +0000)
committerSteven Whitehouse <steve@dolmen.chygwyn.com>
Tue, 24 Mar 2009 11:21:18 +0000 (11:21 +0000)
commitd8348de06f704fc34d24ec068546ecb1045fc11a
treee6b7eb01ec128e40b255b903e3c6629fbd8174e5
parente7c8707ea2b9106f0f78c43348ff5d5e82ba7961
GFS2: Fix deadlock on journal flush

This patch fixes a deadlock when the journal is flushed and there
are dirty inodes other than the one which caused the journal flush.
Originally the journal flushing code was trying to obtain the
transaction glock while running the flush code for an inode glock.
We no longer require the transaction glock at this point in time
since we know that any attempt to get the transaction glock from
another node will result in a journal flush. So if we are flushing
the journal, we can be sure that the transaction lock is still
cached from when the transaction was started.

By inlining a version of gfs2_trans_begin() (minus the bit which
gets the transaction glock) we can avoid the deadlock problems
caused if there is a demote request queued up on the transaction
glock.

In addition I've also moved the umount rwsem so that it covers
the glock workqueue, since it all demotions are done by this
workqueue now. That fixes a bug on umount which I came across
while fixing the original problem.

Reported-by: David Teigland <teigland@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
fs/gfs2/glock.c
fs/gfs2/glops.c
fs/gfs2/trans.c