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>
Showing
- drivers/staging/pohmelfs/path_entry.c 12 additions, 3 deletionsdrivers/staging/pohmelfs/path_entry.c
- fs/autofs4/waitq.c 15 additions, 3 deletionsfs/autofs4/waitq.c
- fs/dcache.c 111 additions, 23 deletionsfs/dcache.c
- fs/nfs/namespace.c 13 additions, 1 deletionfs/nfs/namespace.c
- include/linux/dcache.h 1 addition, 0 deletionsinclude/linux/dcache.h
Loading
Please register or sign in to comment