Messages in this thread | | | Subject | rmdir | From | Magnus Ahltorp <> | Date | 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/
| |