Message-ID: <CAOQ4uxgMiQaMDOifxCuv1Vd=0gsWLjFj0h3t8W-yWB++4ftP0g@mail.gmail.com>
Date: Thu, 17 Jul 2025 08:15:23 +0200
From: Amir Goldstein <amir73il@...il.com>
To: Ed Tsai (蔡宗軒) <Ed.Tsai@...iatek.com>
Cc: "hanqi@...o.com" <hanqi@...o.com>, "miklos@...redi.hu" <miklos@...redi.hu>, 
	"liulei.rjpt@...o.com" <liulei.rjpt@...o.com>, 
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	Chun-Hung Wu (巫駿宏) <Chun-hung.Wu@...iatek.com>, 
	Bernd Schubert <bernd.schubert@...tmail.fm>
Subject: Re: [RFC PATCH] fuse: modification of FUSE passthrough call sequence

On Thu, Jul 17, 2025 at 3:35 AM Ed Tsai (蔡宗軒) <Ed.Tsai@...iatek.com> wrote:
>
> On Wed, 2025-07-16 at 14:14 +0200, Amir Goldstein wrote:
> >
> > External email : Please do not click links or open attachments until
> > you have verified the sender or the content.
> >
> >
> > On Wed, Jul 16, 2025 at 1:49 PM Qi Han <hanqi@...o.com> wrote:
> > >
> > > Hi, Amir
> >
> > Hi Qi,
> >
> > > In the commit [1], performing read/write operations with DIRECT_IO
> > > on
> > > a FUSE file path does not trigger FUSE passthrough. I am unclear
> > > about
> > > the reason behind this behavior. Is it possible to modify the call
> > > sequence to support passthrough for files opened with DIRECT_IO?
> >
> > Are you talking about files opened by user with O_DIRECT or
> > files open by server with FOPEN_DIRECT_IO?
> >
> > Those are two different things.
> > IIRC, O_DIRECT to a backing passthrough file should be possible.
> >
> > > Thank you!
> > >
> > > [1]
> > > https://lore.kernel.org/all/20240206142453.1906268-7-amir73il@gmail.com/
> > >
> > > Reported-by: Lei Liu <liulei.rjpt@...o.com>
> > > Signed-off-by: Qi Han <hanqi@...o.com>
> > > ---
> > >  fs/fuse/file.c | 15 +++++++--------
> > >  1 file changed, 7 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> > > index 2ddfb3bb6483..689f9ee938f1 100644
> > > --- a/fs/fuse/file.c
> > > +++ b/fs/fuse/file.c
> > > @@ -1711,11 +1711,11 @@ static ssize_t fuse_file_read_iter(struct
> > > kiocb *iocb, struct iov_iter *to)
> > >         if (FUSE_IS_DAX(inode))
> > >                 return fuse_dax_read_iter(iocb, to);
> > >
> > > -       /* FOPEN_DIRECT_IO overrides FOPEN_PASSTHROUGH */
> > > -       if (ff->open_flags & FOPEN_DIRECT_IO)
> > > -               return fuse_direct_read_iter(iocb, to);
> > > -       else if (fuse_file_passthrough(ff))
> > > +
> > > +       if (fuse_file_passthrough(ff))
> > >                 return fuse_passthrough_read_iter(iocb, to);
> > > +       else if (ff->open_flags & FOPEN_DIRECT_IO)
> > > +               return fuse_direct_read_iter(iocb, to);
> > >         else
> > >                 return fuse_cache_read_iter(iocb, to);
> > >  }
> > > @@ -1732,11 +1732,10 @@ static ssize_t fuse_file_write_iter(struct
> > > kiocb *iocb, struct iov_iter *from)
> > >         if (FUSE_IS_DAX(inode))
> > >                 return fuse_dax_write_iter(iocb, from);
> > >
> > > -       /* FOPEN_DIRECT_IO overrides FOPEN_PASSTHROUGH */
> > > -       if (ff->open_flags & FOPEN_DIRECT_IO)
> > > -               return fuse_direct_write_iter(iocb, from);
> > > -       else if (fuse_file_passthrough(ff))
> > > +       if (fuse_file_passthrough(ff))
> > >                 return fuse_passthrough_write_iter(iocb, from);
> > > +       else if (ff->open_flags & FOPEN_DIRECT_IO)
> > > +               return fuse_direct_write_iter(iocb, from);
> > >         else
> > >                 return fuse_cache_write_iter(iocb, from);
> > >  }
> > > --
> >
> > When server requests to open a file with FOPEN_DIRECT_IO,
> > it affects how FUSE_READ/FUSE_WRITE requests are made.
> >
> > When server requests to open a file with FOPEN_PASSTHROUGH,
> > it means that FUSE_READ/FUSE_WRITE requests are not to be
> > expected at all, so these two options are somewhat conflicting.
> >
> > Therefore, I do not know what you aim to achieve by your patch.
> >
> > However, please note this comment in iomode.c:
> >  * A combination of FOPEN_PASSTHROUGH and FOPEN_DIRECT_IO
> >    means that read/write
> >  * operations go directly to the server, but mmap is done on the
> > backing file.
> >
> > So this is a special mode that the server can request in order to do
> > passthrough mmap but still send FUSE_READ/FUSE_WRITE requests
> > to the server.
>
> Hi Amir,
>
> In most cases, when using passthrough, the server shouldn't set
> FOPEN_DIRECT_IO, since these two options are conceptually conflicting,
> unless the server specifically wants this special mode (passthrough
> mmap but still send r/w requests). Is that correct?
>

Yes, correct.

See this fix in libfuse for a similar confusion:
https://github.com/libfuse/libfuse/pull/1031

> It can be confusing. Maybe the documentation could clarify this special
> case,

Any documentation would be great.
Documentation patches are most welcome.

> or the passthrough flags for mmap and r/w could be separate...
>

I don't think that's the solution, but it's too hard to explain why
(read fs/fuse/iomode.c to get the idea)

direct_io mode is the mode for doing read/write to the server
without using page cache, so by definition it is not applicable
to mmap().
OTOH, passthrough mode is applicable to read/write/mmap

direct_io mode can be requested EITHER by user (O_DIRECT)
OR by server (FOPEN_DIRECT_IO), therefore setting
FOPEN_DIRECT_IO in server upon user request of O_DIRECT
is somewhat redundant.

However, it is a reason in the libfuse passthrough examples -
Unlike O_DIRECT, which the user can recall after open,
FOPEN_DIRECT_IO is sticky and cannot be changed on an
open file, so that's a way for the server to express, if a user
requested open O_DIRECT, the user cannot back down from this
request, which can be useful for enabling kernel features as parallel DIO.

> >
> > What is your use case? What are you trying to achieve that is not
> > currently possible?
> >
> > Thanks,
> > Amir.
> >
>
> Hi Qi,
>
> I just notice that Android's FuseDaemon doesn't seem to recognize this
> special mode. It sets both FOPEN_DIRECT_IO and FOPEN_PASSTHROUGH when
> the user sets O_DIRECT and the server has passthrough enabled.
>
> If that's your case, I think Android FuseDaemon may need some fixes.
>

Because there is no proper documentation for the interdependencies
of these two modes, let me just say when a server might need to set both flags.

If a server's decision to passthrough io is not always consistent for the same
inode, for example, server wants to passthrough opens for read and not
passthrough open for writes.

This situation is not allowed by kernel iomode restrictions if both
files are open at the same time in conflicting modes.

Unless, the non-passthrough files (e.g. open for write) are open with
FOPEN_DIRECT_IO | FOPEN_PASSTHROUGH.
This mode will not passthrough read/write on this file, but it does not
conflict with other files open (e.g. for read) in passthrough mode.

I know, it's confusing.
The way to think about it is that a passthrough-mostly server
should set FOPEN_PASSTHROUGH for all opens, but it can opt-out
of passthrough read/write on individual files with FOPEN_DIRECT_IO.

And none of this has any relation to O_DIRECT.

Thanks,
Amir.

Powered by blists - more mailing lists