Re: [9fans] Df command in Plan9?

[Alexander Viro <viro@math.psu.edu>]

On Wed, 25 Oct 2000, Douglas A. Gwyn wrote:

> Boyd Roberts wrote:
> > ... it's working out whether
> > you're ripping out the tree from under yourself is the
> > nasty problem.
>
> But that's a move, not a rename.

rename(2) in 4.2BSD and other Unices that picked/inherited it _is_ move.
Yes, it's overcomplicated, it sucks badly wrt required locking, it has
extremely nasty potential for races with rmdir() and itself, yodda, yodda.
I have no idea why Kirk went for that horror. He did. Once it works right
it's a convenient thing to have around, but getting it work right...
<shudder> Apologies for self-quoting, but...
/*
 * The worst of all namespace operations - renaming directory. "Perverted"
 * doesn't even start to describe it. Somebody in UCB had a heck of a trip...
 * Problems:
 *      a) we can get into loop creation. Check is done in is_subdir().
 *      b) race potential - two innocent renames can create a loop  together.
 *         That's where 4.4 screws up. Current fix: serialization on
 *         sb->s_vfs_rename_sem. We might be more accurate, but that's another
 *         story.
 *      c) we have to lock _three_ objects - parents and victim (if it exists).
 *         And that - after we got ->i_sem on parents (until then we don't know
 *         whether the target exists at all, let alone whether it is a directory
 *         or not). Solution: ->i_zombie. Taken only after ->i_sem. Always taken
 *         on link creation/removal of any kind. And taken (without ->i_sem) on
 *         directory that will be removed (both in rmdir() and here).
 *      d) some filesystems don't support opened-but-unlinked directories,
 *         either because of layout or because they are not ready to deal with
 *         all cases correctly. The latter will be fixed (taking this sort of
 *         stuff into VFS), but the former is not going away. Solution: the same
 *         trick as in rmdir().
 *	[ the latter had been fixed, the former == NFS and SMBFS these days ]
 *      e) conversion from fhandle to dentry may come in the wrong moment - when
 *         we are removing the target. Solution: we will have to grab ->i_zombie
 *         in the fhandle_to_dentry code. [FIXME - current nfsfh.c relies on
 *         ->i_sem on parents, which works but leads to some truely excessive
 *         locking].
 */
int vfs_rename_dir(struct inode *old_dir, struct dentry *old_dentry,
               struct inode *new_dir, struct dentry *new_dentry)
{
        int error;
        struct inode *target;

        if (old_dentry->d_inode == new_dentry->d_inode)
                return 0;

        error = may_delete(old_dir, old_dentry, 1);
        if (error)
                return error;

        if (new_dir->i_dev != old_dir->i_dev)
                return -EXDEV;

        if (!new_dentry->d_inode)
                error = may_create(new_dir, new_dentry);
        else
                error = may_delete(new_dir, new_dentry, 1);
        if (error)
                return error;

        if (!old_dir->i_op || !old_dir->i_op->rename)
                return -EPERM;

        /*
         * If we are going to change the parent - check write permissions,
         * we'll need to flip '..'.
         */
        if (new_dir != old_dir)
                error = permission(old_dentry->d_inode, MAY_WRITE);
        if (error)
                return error;

        DQUOT_INIT(old_dir);
        DQUOT_INIT(new_dir);
        down(&old_dir->i_sb->s_vfs_rename_sem);
        error = -EINVAL;
        if (is_subdir(new_dentry, old_dentry))
                goto out_unlock;
        target = new_dentry->d_inode;
        if (target) { /* Hastur! Hastur! Hastur! */
                triple_down(&old_dir->i_zombie,
                            &new_dir->i_zombie,
                            &target->i_zombie);
                d_unhash(new_dentry);
        } else
                double_down(&old_dir->i_zombie,
                            &new_dir->i_zombie);
        if (IS_DEADDIR(old_dir)||IS_DEADDIR(new_dir))
                error = -ENOENT;
        else if (d_mountpoint(old_dentry)||d_mountpoint(new_dentry))
                error = -EBUSY;
        else
                error = old_dir->i_op->rename(old_dir, old_dentry,
					      new_dir, new_dentry);
        if (target) {
                if (!error)
                        target->i_flags |= S_DEAD;
                triple_up(&old_dir->i_zombie,
                          &new_dir->i_zombie,
                          &target->i_zombie);
                if (d_unhashed(new_dentry))
                        d_rehash(new_dentry);
                dput(new_dentry);
        } else
                double_up(&old_dir->i_zombie,
                          &new_dir->i_zombie);

        if (!error)
                d_move(old_dentry,new_dentry);
out_unlock:
        up(&old_dir->i_sb->s_vfs_rename_sem);
        return error;
}

... and that's just the directory-specific part of VFS side of the thing,
after we got i_sem on parents and got dentries of source and target.
->i_op->rename() does fs-dependent part of work.

Full-blown rename() is painful, just as full-blown truncate() and correct
handling of symlinks. Nice to have on the userland side of things, but
kernel side is something. truncate()/mmap()/write() alone makes for a
serious S&M shop.