forked from Minki/linux
949854d024
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> |
||
|---|---|---|
| .. | ||
| autofs_i.h | ||
| dev-ioctl.c | ||
| expire.c | ||
| init.c | ||
| inode.c | ||
| Kconfig | ||
| Makefile | ||
| root.c | ||
| symlink.c | ||
| waitq.c | ||