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: <CAJfpegvxp6Ah3Br9XUmnz_E5KwfOTC44JTa_Sjt0WGt8cAZKEg@mail.gmail.com>
Date: Thu, 13 Mar 2025 11:32:04 +0100
From: Miklos Szeredi <miklos@...redi.hu>
To: Luis Henriques <luis@...lia.com>
Cc: 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 Tue, 11 Mar 2025 at 12:08, Luis Henriques <luis@...lia.com> wrote:

> Well, the use-case I had in mind is, as I mentioned before, CVMFS.  I
> think this file system could benefit from using this mechanism.

We need more than just a hunch that this will work.  Having code out
there that actually uses the new feature is a hard requirement.

It does not need to be actually committed to the cvmfs repo, but some
indication that the code will be accepted by the maintainers once the
kernel part is upstream is needed.

> However, I don't think that measuring the direct benefits is something
> easily done.  At the moment, it uses a thread that tries to drain the
> cache using the FUSE_NOTIFY_INVAL_{INODE,ENTRY} operations.  These are,
> obviously, operations that are much more expensive than the proposed
> FUSE_NOTIFY_INC_EPOCH.  But, on the other hand, they have *immediate*
> effect while the new operation does not: without the call to
> shrink_dcache_sb() it's effect can only be observed in the long run.

How so?  Isn't the advantage of FUSE_NOTIFY_INC_EPOCH that it spares
the server of having to send out FUSE_NOTIFY_INVAL_ENTRY for *all* of
the currently looked up dentries?

> I can try to come up with some artificial test case for this, but
> comparing these operations will always need to be done indirectly.  And I
> wonder how useful that would be.

Any test is better than no test.

> So, you're proposing something like having a workqueue that would walk
> through the entries.  And this workqueue would be triggered when the epoch
> is increased.

Not just.  Also should periodically clean up expired dentries.

Thanks,
Miklos