[Cluster-devel] Fix for unlink deadlock

[Russell Cattelan]

On Wed, 2007-01-31 at 19:17 -0500, Wendy Cheng wrote:
> On Tue, 2007-01-30 at 13:18 +0000, Steven Whitehouse wrote:
> > Hi,
> > 
> > On Mon, 2007-01-29 at 17:13 -0600, Russell Cattelan wrote:
> > > Note the current glock code in the tree is completely busted
> > > and will dead lock almost immediately.
> > > 
> > > I have reverted several changes to glock.c and have 
> > > tested this patch with the older glock code.
> > > dbench will now run through to completion.
> > > 
> > > 
> > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217356
> > 
> > Now applied to the -nmw git tree.
> 
> hmm.. just untar Steve's git tree he sent me this morning few minutes
> ago and spot this - sorry I should have read this post earlier ... Look
> to me this will deadlock gfs2_rename() *again* (since it tries to grab
> rindex lock multiple times). Will test this out tomorrow when I get the
> connectathon cluster up.
> 
I never understood what sequence of events that you found that would
cause the recursive locking, but I tried to set it up such that rename
will only grab the rsgr lock once and outside log locks.

I tested the touch foo foo1 ; mv foo foo1 scenario and it works.

 
> 
> -- Wendy
> 
> 
> >  I think the way to get around the
> > problem with not knowing whether the link count will hit zero is just to
> > remove the code which changes the link count from gfs2_change_nlink and
> > to turn that into a function which just syncs the current link count to
> > the on-disk inode.
> > 
> > It would also solve the problem of needing to work out whether to use
> > inc_nlink() or dec_nlink() to make the change to the link count. Due to
> > the forthcoming read-only bind mounts work, we must always use the
> > macros to change the link count rather than doing it directly.
> > 
> > Steve.
> > 
> > 
-- 
Russell Cattelan <cattelan at redhat.com>