Re: [GIT PULL] fuse update for 6.19

From: Al Viro

Date: Fri Dec 05 2025 - 20:42:23 EST


On Fri, Dec 05, 2025 at 03:47:50PM -0800, Linus Torvalds wrote:
> On Thu, 4 Dec 2025 at 00:25, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> >
> > The stale dentry cleanup has a patch touching dcache.c: this extracts
> > a helper from d_prune_aliases() that puts the unused dentry on a
> > dispose list. Export this and shrink_dentry_list() to modules.
>
> Is that
>
> spin_lock(&dentry->d_lock);
> if (!dentry->d_lockref.count)
> to_shrink_list(dentry, dispose);
> spin_unlock(&dentry->d_lock);
>
> thing possibly hot, and count might be commonly non-zero?
>
> Because it's possible that we could just make it a lockref operation
> where we atomically don't take the lock if the count is non-zero so
> that we don't unnecessarily move cachelines around...
>
> IOW, some kind of "lockref_lock_if_zero()" pattern?
>
> I have no idea what the fuse dentry lifetime patterns might be, maybe
> this is a complete non-issue...

Far more interesting question, IMO, is what's to prevent memory
pressure from evicting the damn argument right under us.

AFAICS, fuse_dentry_tree_work() calls that thing with no locks held.
The one and only reason why that's OK in d_prune_aliases() is ->i_lock
held over that thing - that's enough to prevent eviction. I don't
see anything to serve the same purpose here.