aboutsummaryrefslogtreecommitdiff
path: root/fs/gfs2/locking/dlm
diff options
context:
space:
mode:
authorSteven Whitehouse <swhiteho@redhat.com>2008-11-18 13:38:48 +0000
committerSteven Whitehouse <swhiteho@redhat.com>2009-01-05 07:39:06 +0000
commit813e0c46c9e2a0c6f0b6e774faac82afd7a2e812 (patch)
treecb09aa118f9e053f02e17f7c5ff11139e8e22244 /fs/gfs2/locking/dlm
parent37b2c8377c98acb60cf4d0126e385ef2153bded9 (diff)
GFS2: Fix "truncate in progress" hang
Following on from the recent clean up of gfs2_quotad, this patch moves the processing of "truncate in progress" inodes from the glock workqueue into gfs2_quotad. This fixes a hang due to the "truncate in progress" processing requiring glocks in order to complete. It might seem odd to use gfs2_quotad for this particular item, but we have to use a pre-existing thread since creating a thread implies a GFP_KERNEL memory allocation which is not allowed from the glock workqueue context. Of the existing threads, gfs2_logd and gfs2_recoverd may deadlock if used for this operation. gfs2_scand and gfs2_glockd are both scheduled for removal at some (hopefully not too distant) future point. That leaves only gfs2_quotad whose workload is generally fairly light and is easily adapted for this extra task. Also, as a result of this change, it opens the way for a future patch to make the reading of the inode's information asynchronous with respect to the glock workqueue, which is another improvement that has been on the list for some time now. Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Diffstat (limited to 'fs/gfs2/locking/dlm')
0 files changed, 0 insertions, 0 deletions