linux-kernel - Re: [PATCH v6 2/2] fuse: add new function to invalidate cache for all inodes

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: <CAJfpegszFjRFnnPbetBJrHiW_yCO1mFOpuzp30CCZUnDZWQxqg@mail.gmail.com>
Date: Tue, 18 Feb 2025 10:15:26 +0100
From: Miklos Szeredi <miklos@...redi.hu>
To: Dave Chinner <david@...morbit.com>
Cc: Luis Henriques <luis@...lia.com>, Bernd Schubert <bschubert@....com>, 
	Alexander Viro <viro@...iv.linux.org.uk>, Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>, 
	Matt Harvey <mharvey@...ptrading.com>, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 2/2] fuse: add new function to invalidate cache for all inodes

On Tue, 18 Feb 2025 at 01:55, Dave Chinner <david@...morbit.com> wrote:
>
> On Mon, Feb 17, 2025 at 01:32:28PM +0000, Luis Henriques wrote:
> > Currently userspace is able to notify the kernel to invalidate the cache
> > for an inode.  This means that, if all the inodes in a filesystem need to
> > be invalidated, then userspace needs to iterate through all of them and do
> > this kernel notification separately.
> >
> > This patch adds a new option that allows userspace to invalidate all the
> > inodes with a single notification operation.  In addition to invalidate
> > all the inodes, it also shrinks the sb dcache.
>
> You still haven't justified why we should be exposing this
> functionality in a low level filesystem ioctl out of sight of the
> VFS.
>
> User driven VFS cache invalidation has long been considered a
> DOS-in-waiting, hence we don't allow user APIs to invalidate caches
> like this. This is one of the reasons that /proc/sys/vm/drop_caches
> requires root access - it's system debug and problem triage
> functionality, not a production system interface....
>
> Every other situation where filesystems invalidate vfs caches is
> during mount, remount or unmount operations.  Without actually
> explaining how this functionality is controlled and how user abuse
> is not possible (e.g. explain the permission model and/or how only
> root can run this operation), it is not really possible to determine
> whether we should unconditional allow VFS cache invalidation outside
> of the existing operation scope....

I think you are grabbing the wrong end of the stick here.

This is not about an arbitrary user being able to control caching
behavior of a fuse filesystem.  It's about the filesystem itself being
able to control caching behavior.

I'm not arguing for the validity of this particular patch, just saying
that something like this could be valid.  And as explained in my other
reply there's actually a real problem out there waiting for a
solution.

Thanks,
Miklos


>
> FInally, given that the VFS can only do best-effort invalidation
> and won't provide FUSE (or any other filesystem) with any cache
> invalidation guarantees outside of specific mount and unmount
> contexts, I'm not convinced that this is actually worth anything...
>
> -Dave.
> --
> Dave Chinner
> david@...morbit.com