linux-kernel - Re: [RFC PATCH v5 1/2] fuse: new work queue to periodically invalidate expired dentries

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJfpeguPytg1b4k3jRuCHzXMUbwh6AT3Q4rptnVoRrHOA0PHMA@mail.gmail.com>
Date: Thu, 4 Sep 2025 17:12:21 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: Luis Henriques <luis@...lia.com>
Cc: Bernd Schubert <bernd@...ernd.com>, Laura Promberger <laura.promberger@...n.ch>, 
	Dave Chinner <david@...morbit.com>, Matt Harvey <mharvey@...ptrading.com>, 
	linux-fsdevel@...r.kernel.org, kernel-dev@...lia.com, 
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v5 1/2] fuse: new work queue to periodically
 invalidate expired dentries

On Thu, 4 Sept 2025 at 16:00, Luis Henriques <luis@...lia.com> wrote:
>
> Hi Miklos,
>
> On Thu, Sep 04 2025, Miklos Szeredi wrote:
>
> > On Thu, 28 Aug 2025 at 18:30, Luis Henriques <luis@...lia.com> wrote:

> >> +       if (!inval_wq && RB_EMPTY_NODE(&fd->node))
> >> +               return;
> >
> > inval_wq can change to zero, which shouldn't prevent removing from the rbtree.
>
> Maybe I didn't understood your comment, but isn't that what's happening
> here?  If the 'fd' is in a tree, it will be removed, independently of the
> 'inval_wq' value.

I somehow thought it was || not &&.

But I still don't see the point.  The only caller already checked
RB_EMPTY_NODE, so that is false. No race possible since it's called
form the destruction of the dentry, and so this expression is
guaranteed to evaluate to false.

> (By the way, I considered using mutexes here instead.  Do you have any
> thoughts on this?)

Use mutex where protected code might sleep, spin lock otherwise.

>
> What I don't understand in your comment is where you suggest these helpers
> could be in a higher level.  Could you elaborate on what exactly you have
> in mind?

E.g.

void d_dispose_if_unused(struct dentry *dentry, struct list_head *dispose)
{
        spin_lock(&dentry->d_lock);
        if (!dentry->d_lockref.count)
                to_shrink_list(dentry, dispose);
        spin_unlock(&dentry->d_lock);
}

Which is in fact taken from d_prune_aliases(), which could be modified
to use this helper.

Thanks,
Miklos