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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
