[OpenAFS-devel] Re: OpenAFS client crashes on RHEL 5.10 and RHEL 6.5

[J. Bruce Fields]

On Tue, Mar 18, 2014 at 02:24:55PM -0500, Andrew Deason wrote:
> On Tue, 18 Mar 2014 14:16:12 -0500
> Andrew Deason <adeason@sinenomine.net> wrote:
> 
> [RHEL patch]
> > ------------------
> > 
> > That seems like it gets rid of any problems. Now 'new' will be NULL if
> > it finds a "non-moveable alias", so we still get to use our aliased
> > dentry. If the duplicate mount point is in the same parent dir, it may
> > be a little strange since we may ping-pong d_move'ing back and forth
> > between the entries, but I can't find any actual problems with that
> > happening.
> 
> However, that is just the targeted fix for RHEL. I was pointed at this
> for the upstream direction:
> <http://thread.gmane.org/gmane.comp.file-systems.btrfs/32714/focus=82546>
> 
> Honestly I haven't had time yet to look at that very closely, but
> according to the 'documentation' patch in that series, it still seems
> like we are prohibited from directory aliases so it seems like that may
> still be a problem.
> 
> CC'ing J. Bruce Fields, if he has anything to say about this.
> d_materialise_unique still seems like it would be problematic to me, as
> I mentioned earlier, since using it can result in vfs_rmdir'ing a dentry
> where our parent inode does not match the dentry's d_parent->d_inode,
> which can panic may_delete. But it's very possible I am missing
> something here.

Both the d_move case of d_materialise_unique and the vfs_rmdir take the
i_mutex on the parent directories involved, so they'll be serialised
with respect to each other and I don't think you should see that panic.

The one nit is that d_materialise_unique depends on a trylock for that
so whoever does the lookup can get a spurious -EBUSY if they're unlucky.

But it sounds like you can avoid these multiply-linked directories by
creating mountpoints at the appropriate places, as the NFS client does.

--b.