summaryrefslogtreecommitdiff
path: root/Documentation/filesystems/porting
diff options
context:
space:
mode:
authorNick Piggin <npiggin@kernel.dk>2011-01-07 17:49:23 +1100
committerNick Piggin <npiggin@kernel.dk>2011-01-07 17:50:18 +1100
commitfe15ce446beb3a33583af81ffe6c9d01a75314ed (patch)
treebc8af66b6dd2d0f21a2a3f48a19975ae2cdbae4e /Documentation/filesystems/porting
parent5eef7fa905c814826f518aca2d414ca77508ce30 (diff)
fs: change d_delete semantics
Change d_delete from a dentry deletion notification to a dentry caching advise, more like ->drop_inode. Require it to be constant and idempotent, and not take d_lock. This is how all existing filesystems use the callback anyway. This makes fine grained dentry locking of dput and dentry lru scanning much simpler. Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Diffstat (limited to 'Documentation/filesystems/porting')
-rw-r--r--Documentation/filesystems/porting8
1 files changed, 8 insertions, 0 deletions
diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting
index b12c89538680..9e71c9ad3108 100644
--- a/Documentation/filesystems/porting
+++ b/Documentation/filesystems/porting
@@ -318,3 +318,11 @@ if it's zero is not *and* *never* *had* *been* enough. Final unlink() and iput(
may happen while the inode is in the middle of ->write_inode(); e.g. if you blindly
free the on-disk inode, you may end up doing that while ->write_inode() is writing
to it.
+
+---
+[mandatory]
+
+ .d_delete() now only advises the dcache as to whether or not to cache
+unreferenced dentries, and is now only called when the dentry refcount goes to
+0. Even on 0 refcount transition, it must be able to tolerate being called 0,
+1, or more times (eg. constant, idempotent).