lkml.org 
[lkml]   [1999]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Subjectrmdir
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.026 / U:1.676 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site