vfs_rmdir "bug"?

[Erez Zadok <ezk@cs.sunysb.edu>]

Al, Christoph,

vfs_rmdir is called from do_rmdir and does essentially this:

	dentry_unhash(dentry);
	error = dir->i_op->rmdir(dir, dentry);
	if (!error)
		d_delete(dentry);
	dput(dentry);


do_rmdir grabs a ref on the dentry to be rmdir'ed, and also dput's it (so
it's nice and symmetric).  But vfs_rmdir seems asymmetric esp. when ->rmdir
returns and error (e.g., -ENOTEMPTY):

1. on error, the dentry will remain unhashed: shouldn't it be re-hashed (the
   way vfs_rename_dir does)?

2. vfs_rmdir unconditionally dput's the dentry, but it never grabbed that
   ref in the first place.  Is this really necessary.  We had a good dentry
   in the dcache before the call to rmdir(2), but after this unconditional
   dput(), it'll be removed from the dcache.  This would cause the vfs to
   have to re-issue a lookup on it next time someone tries to do anything
   with that directory.

I discovered this while trying to figure out why an expected-to-fail rmdir
on unionfs (one of the ltp tests tests for -ENOTEMPTY) left a lower inode
behind until umount(2) was called.  I fixed it by implementing
unionfs_d_iput, but still, it seems odd that we'll have dropped/unhashed a
possibly good dentry b/c ->rmdir failed.

Thanks,
Erez.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/