Patch "fast_dput(): handle underflows gracefully" has been added to the 5.15-stable tree

[Sasha Levin <sashal@xxxxxxxxxx>]

This is a note to let you know that I've just added the patch titled

    fast_dput(): handle underflows gracefully

to the 5.15-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     fast_dput-handle-underflows-gracefully.patch
and it can be found in the queue-5.15 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit fb1fcd361d3cf5e4ba3e4cb1a718559eff0b26b6
Author: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
Date:   Wed Nov 1 01:08:54 2023 -0400

    fast_dput(): handle underflows gracefully
    
    [ Upstream commit 504e08cebe1d4e1efe25f915234f646e74a364a8 ]
    
    If refcount is less than 1, we should just warn, unlock dentry and
    return true, so that the caller doesn't try to do anything else.
    
    Taking care of that leaves the rest of "lockref_put_return() has
    failed" case equivalent to "decrement refcount and rejoin the
    normal slow path after the point where we grab ->d_lock".
    
    NOTE: lockref_put_return() is strictly a fastpath thing - unlike
    the rest of lockref primitives, it does not contain a fallback.
    Caller (and it looks like fast_dput() is the only legitimate one
    in the entire kernel) has to do that itself.  Reasons for
    lockref_put_return() failures:
            * ->d_lock held by somebody
            * refcount <= 0
            * ... or an architecture not supporting lockref use of
    cmpxchg - sparc, anything non-SMP, config with spinlock debugging...
    
    We could add a fallback, but it would be a clumsy API - we'd have
    to distinguish between:
            (1) refcount > 1 - decremented, lock not held on return
            (2) refcount < 1 - left alone, probably no sense to hold the lock
            (3) refcount is 1, no cmphxcg - decremented, lock held on return
            (4) refcount is 1, cmphxcg supported - decremented, lock *NOT* held
                on return.
    We want to return with no lock held in case (4); that's the whole point of that
    thing.  We very much do not want to have the fallback in case (3) return without
    a lock, since the caller might have to retake it in that case.
    So it wouldn't be more convenient than doing the fallback in the caller and
    it would be very easy to screw up, especially since the test coverage would
    suck - no way to test (3) and (4) on the same kernel build.
    
    Reviewed-by: Christian Brauner <brauner@xxxxxxxxxx>
    Signed-off-by: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/fs/dcache.c b/fs/dcache.c
index cf871a81f4fd..422c440b492a 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -762,12 +762,12 @@ static inline bool fast_dput(struct dentry *dentry)
 	 */
 	if (unlikely(ret < 0)) {
 		spin_lock(&dentry->d_lock);
-		if (dentry->d_lockref.count > 1) {
-			dentry->d_lockref.count--;
+		if (WARN_ON_ONCE(dentry->d_lockref.count <= 0)) {
 			spin_unlock(&dentry->d_lock);
 			return true;
 		}
-		return false;
+		dentry->d_lockref.count--;
+		goto locked;
 	}
 
 	/*
@@ -825,6 +825,7 @@ static inline bool fast_dput(struct dentry *dentry)
 	 * else could have killed it and marked it dead. Either way, we
 	 * don't need to do anything else.
 	 */
+locked:
 	if (dentry->d_lockref.count) {
 		spin_unlock(&dentry->d_lock);
 		return true;