Re: processes hung after sys_renameat, and 'missing' processes

[Al Viro <viro@ZenIV.linux.org.uk>]

On Fri, Jun 08, 2012 at 12:54:00AM -0700, Eric W. Biederman wrote:
> > Please, explain.  link/unlink pair in which sense? 
> 
> In the sense that if we don't use d_move.  A rename will look to
> userspace like a pair of sys_link and sys_unlink operations.
> 
> If I happen to have a file open with the old name and the dentry passes
> through d_drop.  The /proc/self/fd/N will show the filename as
> "...(deleted)".

Um... reality check, please - you were talking about symlinks until now.  Sure,
these days we *can* open them (with O_PATH), but...  And unless I'm misreading
something, none of those sysfs_rename() callers are acting on regular files.

In any case, symlinks or no symlinks, what do you expect to happen if
something in userland does lookup at the old location before anyone gets
around to lookup at the new one?  It's not as if that had been under
kernel control...

> In the little corner case user visible details the current state of vfs
> support for distributed filesystems looks nuts to me, especially where
> we can't apply an appropriate d_move onto a renamed dentry.

Reread your own code, please.  You are *not* guaranteed that lookup triggering
that d_move() of yours will come before ->d_revalidate().  In other words,
the current scheme is not any different in that respect.  And nothing in
userland really cares - scenario is too convoluted.

> Speaking of I just found a small unhandled case in __d_unalias.  We need
> to deny renaming of mount points.

Umm...  Agreed, fix pushed into the same branch.