On Tue, Mar 18, 2014 at 02:24:55PM -0500, Andrew Deason wrote: > On Tue, 18 Mar 2014 14:16:12 -0500 > Andrew Deason <[email protected]> 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. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
