rmdir

Magnus Ahltorp (map@stacken.kth.se)
10 Jan 1999 01:10:15 +0100


What are the semantics for the rmdir implementation in a file system
(in 2.1 & 2.2)? In my file system implementation, I do d_delete() on
the dentry when I'm finished doing my stuff, but as far as I can tell,
that will not have any effect, since

1) The d_count will be (at least) 2
2) d_delete() only does d_drop() if the d_count != 1
3) d_drop() only unhashes the dentry, which was already done by vfs_rmdir().

So, it seems the d_delete() call is unnecessary. But why do most file
systems do d_delete()? Did the d_delete() call in rmdir become
unnecessary when the new rmdir locking things were implemented?

I have another question regarding this. As far as I can tell, the
d_count is:

1) increased with 1 in the lookup_dentry() in do_rmdir()
2) increased with 1 just before the double_lock in do_rmdir()
3) unchanged in vfs_rmdir()
4) unchanged in the file systems rmdir()
5) decreased by 1 in dput() in the end of do_rmdir()

This leaves us with 1 extra reference count. Why? Is it a bug? Is it
meant that way?

/Magnus
map@stacken.kth.se

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