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

[Andrew Deason]

On Tue, 18 Mar 2014 16:01:26 -0400
"J. Bruce Fields" <bfields@redhat.com> wrote:

> > 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.

Yes, I see.

> 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.

Via __d_unalias, yeah, that looks like it would make it unsuitable. But
the restrictions on directory loops maybe makes this unsuitable anyway.

Is the reasoning for the trylocks just lock ordering? It seems odd to me
that lookups for anything using d_materialise_unique can seem to just
randomly fail.

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

We are also pursuing this approach (again) ever since the recent RHEL
"regression" was reported. This is very difficult to implement while
avoiding GPLONLY symbols, though, as we must perform all of the mounts
and umounts from userspace. It seems possible, but it just takes a lot
of work to avoid numerous issues, and will take some time.

I don't suppose there's any way the GPLONLY restriction on those
interfaces could change? Or do you have any other suggestions or
anything as to an approach we should be taking?

-- 
Andrew Deason
adeason@sinenomine.net