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@xxxxxxxxxxxxxxxxxx>
---
fs/dcache.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/fs/dcache.c b/fs/dcache.c
index c89337ae30ce..7931f5108581 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -739,14 +739,10 @@ static struct dentry *dentry_kill(struct dentry *dentry)
spin_lock(&dentry->d_lock);
parent = lock_parent(dentry);
got_locks:
- if (unlikely(dentry->d_lockref.count != 1)) {
- dentry->d_lockref.count--;
- } else if (likely(!retain_dentry(dentry))) {
- dentry->d_lockref.count--;
+ dentry->d_lockref.count--;
+ if (likely(dentry->d_lockref.count == 0)) {
__dentry_kill(dentry);
return parent;
- } else {
- dentry->d_lockref.count--;
}
/* we are keeping it, after all */
if (inode)
--
2.39.2
