aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/Documentation/filesystems
diff options
context:
space:
mode:
authorAl Viro <viro@zeniv.linux.org.uk>2023-10-31 00:23:35 -0400
committerAl Viro <viro@zeniv.linux.org.uk>2023-11-25 02:33:42 -0500
commitb06c684d3984ef64e792ec3e89889c96cab97b5e (patch)
treec1f0d16c9ac339a158c33fcb7240250d5019abf8 /Documentation/filesystems
parent__dentry_kill(): get consistent rules for victim's refcount (diff)
downloadwireguard-linux-b06c684d3984ef64e792ec3e89889c96cab97b5e.tar.xz
wireguard-linux-b06c684d3984ef64e792ec3e89889c96cab97b5e.zip
dentry_kill(): don't bother with retain_dentry() on slow path
We have already checked it and dentry used to look not worthy of keeping. The only hard obstacle to evicting dentry is non-zero refcount; everything else is advisory - e.g. memory pressure could evict any dentry found with refcount zero. On the slow path in dentry_kill() we had dropped and regained ->d_lock; we must recheck the refcount, but everything else is not worth bothering with. Note that filesystem can not count upon ->d_delete() being called for dentry - not even once. Again, memory pressure (as well as d_prune_aliases(), or attempted rmdir() of ancestor, or...) will not call ->d_delete() at all. So from the correctness point of view we are fine doing the check only once. And it makes things simpler down the road. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'Documentation/filesystems')
0 files changed, 0 insertions, 0 deletions