Re: [PATCH 10/22] fast_dput(): new rules for refcount

[Al Viro <viro@zeniv.linux.org.uk>]

On Thu, Nov 09, 2023 at 03:54:34PM +0100, Christian Brauner wrote:
> On Thu, Nov 09, 2023 at 06:20:44AM +0000, Al Viro wrote:
> > Currently the "need caller to do more work" path in fast_dput()
> > has refcount decremented, then, with ->d_lock held and
> > refcount verified to have reached 0 fast_dput() forcibly resets
> > the refcount to 1.
> > 
> > Move that resetting refcount to 1 into the callers; later in
> > the series it will be massaged out of existence.
> > 
> > Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> > ---
> 
> Ok, this is safe to do because of
> 
> [PATCH 09/22] fast_dput(): handle underflows gracefully
> https://lore.kernel.org/linux-fsdevel/20231109062056.3181775-9-viro@zeniv.linux.org.uk
> 
> as return false from fast_dput() now always means refcount is zero.

Not sure how to put it in commit message cleanly.  Perhaps something
like the following variant?

By now there is only one place in entire fast_dput() where we return
false; that happens after refcount had been decremented and found
(while holding ->d_lock) to be zero.  In that case, just prior to
returning false to caller, fast_dput() forcibly changes the refcount
from 0 to 1.

Lift that resetting refcount to 1 into the callers; later in
the series it will be massaged out of existence.