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: <875xkdfa0d.fsf@igalia.com>
Date: Thu, 13 Mar 2025 11:25:06 +0000
From: Luis Henriques <luis@...lia.com>
To: Miklos Szeredi <miklos@...redi.hu>
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 Thu, Mar 13 2025, Miklos Szeredi wrote:

> 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.

OK, makes sense.  I do have a local cvmfs patch to use this new
notification.  For now it's just a hack to replace the current code.  It
has to be cleaned-up so that it uses FUSE_NOTIFY_INC_EPOCH only when it's
available in libfuse.  My plan was to do this only after the kernel patch
was merged, but I can try to share an earlier version of it.

>> 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?

Well, I guess I misunderstood you.  I can use my hacked cvmfs to measure
the improvement of removing this loop and replace it with a single
FUSE_NOTIFY_INC_EPOCH.  Obviously, the performance improvements will
depend on how many dentries were cached.

>> 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.

Hmmm... And would you like this to be done in fuse?  Or do you expect this
to me a more generic mechanism in dcache, available for other filesystems
as well?

Cheers,
-- 
Luís