[Cluster-devel] [PATCH] Fix change nlink deadlock

[Cluster-devel] [PATCH] Fix change nlink deadlock

[Wendy Cheng]

Bugzilla 215088

Fix deadlock in gfs2_change_nlink() while installing RHEL5 into GFS2 
partition. The gfs2_rename() apparently needs block allocation for the 
new name (into the directory) where it requires rg locks. At the same 
time, while updating the nlink count for the replaced file, 
gfs2_change_nlink() tries to return the inode meta-data back to resource 
group where it needs rg locks too. Our logic doesn't allow process to 
acquire these locks recursively by the same process  (RHEL installer) 
that results a BUG call. This only happens within rename code path and 
only if the destination file exists before the rename operation.

Patch passed a simulated test program created for this issue yesterday - 
havn't really tried it out on installer yet. Will continue to installer 
test today. Pass it up for a quick eyeball examine.

-- Wendy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gfs2_rename_nlink.patch
Type: text/x-patch
Size: 2580 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/cluster-devel/attachments/20061215/58088dfc/attachment.bin>

[Cluster-devel] [PATCH] Fix change nlink deadlock

[Steven Whitehouse]

Hi,

On Fri, 2006-12-15 at 09:50 -0500, Wendy Cheng wrote:
> Bugzilla 215088
> 
> Fix deadlock in gfs2_change_nlink() while installing RHEL5 into GFS2 
> partition. The gfs2_rename() apparently needs block allocation for the 
> new name (into the directory) where it requires rg locks. At the same 
> time, while updating the nlink count for the replaced file, 
> gfs2_change_nlink() tries to return the inode meta-data back to resource 
> group where it needs rg locks too. Our logic doesn't allow process to 
> acquire these locks recursively by the same process  (RHEL installer) 
> that results a BUG call. This only happens within rename code path and 
> only if the destination file exists before the rename operation.
> 
> Patch passed a simulated test program created for this issue yesterday - 
> havn't really tried it out on installer yet. Will continue to installer 
> test today. Pass it up for a quick eyeball examine.
> 
> -- Wendy

That looks good to me, so let me know if it passes the tests and I'll
push the patch into the -nmw tree in that case,

Steve.

[Cluster-devel] [PATCH] Fix change nlink deadlock

[Wendy Cheng]

>
> That looks good to me, so let me know if it passes the tests and I'll
> push the patch into the -nmw tree in that case,
>   
Steve, ok, as long as you agree with the approach ... There is another 
panic - when the new and old inodes are located in different RGs. Here 
is the revised patch. No installer testing yet but this makes great 
improvement for the single node gfs2 rename.

-- Wendy








-------------- next part --------------
A non-text attachment was scrubbed...
Name: gfs2_nlink.patch
Type: text/x-patch
Size: 3487 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/cluster-devel/attachments/20061215/93372351/attachment.bin>

[Cluster-devel] [PATCH] Fix change nlink deadlock

[Steven Whitehouse]

Hi,

On Fri, 2006-12-15 at 14:44 -0500, Wendy Cheng wrote:
> >
> > That looks good to me, so let me know if it passes the tests and I'll
> > push the patch into the -nmw tree in that case,
> >   
> Steve, ok, as long as you agree with the approach ... There is another 
> panic - when the new and old inodes are located in different RGs. Here 
> is the revised patch. No installer testing yet but this makes great 
> improvement for the single node gfs2 rename.
> 
> -- Wendy
> 

This is now added to the -nmw git tree. Please check to see that its ok
as I had to fix up a little whitespace breakage and couple of
conversions from ip->i_di.di_nlink to ip->i_inode.i_nlink in order for
it to apply,

Steve.