summaryrefslogtreecommitdiffstats
path: root/include/linux/dcache.h
diff options
context:
space:
mode:
authorNick Piggin <npiggin@kernel.dk>2011-01-07 17:49:37 +1100
committerNick Piggin <npiggin@kernel.dk>2011-01-07 17:50:22 +1100
commit949854d02455080d20cd3e1db28a3a18daf7599d (patch)
tree9b13a6f86c1d0b91e462a471e53b0e717036b18e /include/linux/dcache.h
parent9abca36087288fe28de4749c71ca003d4b9e3ed0 (diff)
downloadlinux-949854d02455080d20cd3e1db28a3a18daf7599d.tar.gz
linux-949854d02455080d20cd3e1db28a3a18daf7599d.tar.xz
fs: Use rename lock and RCU for multi-step operations
The remaining usages for dcache_lock is to allow atomic, multi-step read-side operations over the directory tree by excluding modifications to the tree. Also, to walk in the leaf->root direction in the tree where we don't have a natural d_lock ordering. This could be accomplished by taking every d_lock, but this would mean a huge number of locks and actually gets very tricky. Solve this instead by using the rename seqlock for multi-step read-side operations, retry in case of a rename so we don't walk up the wrong parent. Concurrent dentry insertions are not serialised against. Concurrent deletes are tricky when walking up the directory: our parent might have been deleted when dropping locks so also need to check and retry for that. We can also use the rename lock in cases where livelock is a worry (and it is introduced in subsequent patch). Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Diffstat (limited to 'include/linux/dcache.h')
-rw-r--r--include/linux/dcache.h1
1 files changed, 1 insertions, 0 deletions
diff --git a/include/linux/dcache.h b/include/linux/dcache.h
index bda5ec0b077d..c963ebada922 100644
--- a/include/linux/dcache.h
+++ b/include/linux/dcache.h
@@ -180,6 +180,7 @@ struct dentry_operations {
#define DCACHE_FSNOTIFY_PARENT_WATCHED 0x0080 /* Parent inode is watched by some fsnotify listener */
#define DCACHE_CANT_MOUNT 0x0100
+#define DCACHE_GENOCIDE 0x0200
extern spinlock_t dcache_inode_lock;
extern spinlock_t dcache_lock;