Re: [PATCH v14 00/12] FUSE passthrough for file io

From: Miklos Szeredi <miklos@szeredi.hu>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Bernd Schubert <bernd.schubert@fastmail.fm>,
	Daniel Rosenberg <drosen@google.com>,
	 Paul Lawrence <paullawrence@google.com>,
	Alessio Balsini <balsini@android.com>,
	 Christian Brauner <brauner@kernel.org>,
	fuse-devel@lists.sourceforge.net,  linux-fsdevel@vger.kernel.org,
	Dave Chinner <david@fromorbit.com>
Subject: Re: [PATCH v14 00/12] FUSE passthrough for file io
Date: Wed, 29 Nov 2023 17:55:36 +0100	[thread overview]
Message-ID: <CAJfpegtOt6MDFM3vsK+syJhpLMSm7wBazkXuxjRTXtAsn9gCuA@mail.gmail.com> (raw)
In-Reply-To: <CAOQ4uxgW6xpWW=jLQJuPKOCxN=i_oNeRwNnMEpxOhVD7RVwHHw@mail.gmail.com>

On Wed, 29 Nov 2023 at 16:52, Amir Goldstein <amir73il@gmail.com> wrote:

> direct I/O read()/write() is never a problem.
>
> The question is whether mmap() on a file opened with FOPEN_DIRECT_IO
> when the inode is in passthrough mode, also uses fuse_passthrough_mmap()?

I think it should.

> or denied, similar to how mmap with ff->open_flags & FOPEN_DIRECT_IO &&
> vma->vm_flags & VM_MAYSHARE) && !fc->direct_io_relax
> is denied?

What would be the use case for FOPEN_DIRECT_IO with passthrough mmap?

> A bit more challenging, because we will need to track unmounts, or at
> least track
> "was_cached_mmaped" state per file, but doable.

Tracking unmaps via fuse_vma_close() should not be difficult.

>
> > >
> > > Therefore, my proposal is than when filesystem is FUSE_PASSTHROUGH capable,
> > > only passthrough file and cached file may be mmaped, but never allow to
> > > mmap a FOPEN_DIRECT_IO file.
> > >
> > > Does that make sense?
> >
> > I'm not sure I understand how this is supposed to work.   Disallowing
> > mmap will break applications.
>
> How is this different from existing -ENODEV in fuse_file_mmap() for
> !fc->direct_io_relax? What am I missing?
> Is it because VM_MAYSHARE is far less common for applications?

Yes, MAP_SHARE is far less common than MAP_PRIVATE.

Thanks,
Miklos