diff options
author | David Howells <dhowells@redhat.com> | 2011-06-07 13:09:20 (GMT) |
---|---|---|
committer | Al Viro <viro@zeniv.linux.org.uk> | 2011-08-01 06:27:57 (GMT) |
commit | c6627c60c07c43b51ef88e352627fa786d1e1592 (patch) | |
tree | 2d0924acf0c6fa37d0fc7277a9f17940496b6461 /fs/bfs | |
parent | 35f40ef00204c456f5c181c0e7f54e25bb93cd49 (diff) | |
download | linux-fsl-qoriq-c6627c60c07c43b51ef88e352627fa786d1e1592.tar.xz |
VFS: Remove dentry->d_lock locking from shrink_dcache_for_umount_subtree()
Locks of the dcache_lock were replaced by locks of dentry->d_lock in commits
such as:
2304450783dfde7b0b94ae234edd0dbffa865073
2fd6b7f50797f2e993eea59e0a0b8c6399c811dc
as part of the RCU-based pathwalk changes, despite the fact that the caller
(shrink_dcache_for_umount()) notes in the banner comment the reasons that
d_lock is not necessary in these functions:
/*
* destroy the dentries attached to a superblock on unmounting
* - we don't need to use dentry->d_lock because:
* - the superblock is detached from all mountings and open files, so the
* dentry trees will not be rearranged by the VFS
* - s_umount is write-locked, so the memory pressure shrinker will ignore
* any dentries belonging to this superblock that it comes across
* - the filesystem itself is no longer permitted to rearrange the dentries
* in this superblock
*/
So remove these locks. If the locks are actually necessary, then this banner
comment should be altered instead.
The hash table chains are protected by 1-bit locks in the hash table heads, so
those shouldn't be a problem.
Note that to make this work, __d_drop() has to be split so that the RCUwalk
barrier can be avoided. This causes problems otherwise as it has an assertion
that dentry->d_lock is locked - but there is no need for that as no one else
can be trying to access this dentry, except to step over it (and that should
be handled by d_free(), I think).
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'fs/bfs')
0 files changed, 0 insertions, 0 deletions