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>

diff --git a/fs/dcache.c b/fs/dcache.c
index b527db8e5901e29d4f119abfe9c7d1872064e6f0..80992e49561c008d1e86bf9ff78e95ca71fdd6bd 100644 (file)
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -739,14 +739,10 @@ slow_positive:
        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)