linux-kernel - Re: [PATCH v8] fuse: add more control over cache invalidation behaviour

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: <CAJfpegtG2PS0_moONf_ZmLncv1EH7HtC_8ZYxwkEiGZy4cYZaA@mail.gmail.com>
Date: Thu, 13 Mar 2025 11:24:51 +0100
From: Miklos Szeredi <miklos@...redi.hu>
To: Bernd Schubert <bernd@...ernd.com>
Cc: Luis Henriques <luis@...lia.com>, Bernd Schubert <bschubert@....com>, 
	Dave Chinner <david@...morbit.com>, Matt Harvey <mharvey@...ptrading.com>, 
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8] fuse: add more control over cache invalidation behaviour

On Mon, 10 Mar 2025 at 21:11, Bernd Schubert <bernd@...ernd.com> wrote:

> Can't that be done in fuse-server? Maybe we should improve
> notifications to allow a batch of invalidations?
>
> I'm a bit thinking about
> https://github.com/libfuse/libfuse/issues/1131
>
> I.e. userspace got out of FDs and my guess is it happens
> because of dentry/inode cache in the kernel. Here userspace
> could basically need to create its own LRU and then send
> invalidations. It also could be done in kernel,
> but kernel does not know amount of max open userspace FDs.
> We could add it into init-reply, but wouldn't be better
> to keep what we can in userspace?

Two different things:

1) trimming the cache: this is what you are taking about above.  I
don't think it's possible to move the LRU to userspace since it
doesn't see cache accesses and also does not have information about
some references (e.g. cwd). This can be solved by adding a
notification (FUSE_NOTIFY_TRIM) that tell the kernel to evict  N
*unused* dentries (valid or invalid).

2) cleaning up of invalid dentries.  Dentries can become invalid by
explicit invalidation or by expiring the timeout.  The latter is a bit
of a challenge to clean up, as we don't want to start a timer for each
dentry.   This is what I was suggesting instead of an explicit
shrink_dcache_sb().

Thanks,
Miklos