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

From: Amir Goldstein <amir73il@gmail.com>
To: Miklos Szeredi <miklos@szeredi.hu>
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: Tue, 31 Oct 2023 19:44:23 +0200	[thread overview]
Message-ID: <CAOQ4uxiBu8bZ4URhwKuMeHB_Oykz2LHY8mXA1eB3FBoeM_Vs6w@mail.gmail.com> (raw)
In-Reply-To: <CAJfpegs1v=JKaEREORbTsvyTe02_DgkFhNSEJKR6xpjUW1NBDg@mail.gmail.com>

On Tue, Oct 31, 2023 at 5:01 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Tue, 31 Oct 2023 at 13:31, Amir Goldstein <amir73il@gmail.com> wrote:
>
> > Current patch set does not implement "backing inode" for FUSE inode,
>
> What prevents us from storing a fuse_backing reference in fuse_inode
> while the file(s) are open?
>
> AFAICS it just needs a counter in fuse_inode to account the number of
> open instances.
>

The current patches do not enforce that all fuse_file of the same fuse_inode
passthrough to the same backing_file (or same backing inode).

I agree that functionally, we could enforce that, and it may be good for
"backing inode" mapping on lookup going forward
The problem is that at the time of FUSE_DEV_IOC_BACKING_OPEN,
we do not know which fuse_inode is going to be associated with the
fuse_backing object.

v13 patches had a mode that pass nodeid with the fuse_backing_map
request (inode bound mode) and refcount the fuse_backing object
from the fuse_inode (with no backing idr) at the time of the ioctl and
then -EBUSY could be returned for a conflicting backing map request.

The problem with that API was with CREATE of a new nodeid, where
the FUSE_DEV_IOC_BACKING_OPEN ioctl happens before fuse
knows about the new nodeid.

In that case, we would be able to "attach" the fuse_backing object
to fuse_inode on CREATE response. If we end up with a backing map
conflict at this point, we can return -EBUSY error to the user and forget
the inode, but the server would have no easy feedback on its mistake.
Also, -EBUSY to user would be confusing if user did not request O_EXCL.

Do you consider the described "atomic_open conflict" case an API problem?

It is true that with v14 patches that do not enforce backing inode conflicts,
the attribute coherency model that I proposed may result in attribute
cache thrashing if the backing inode of a fuse inode is ambiguous.

Do you have an idea how to handle this case elegantly?

Thanks,
Amir.