Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Alessio Balsini <firstname.lastname@example.org>
To: Miklos Szeredi <email@example.com>
Cc: Alessio Balsini <firstname.lastname@example.org>,
Akilesh Kailash <email@example.com>,
Amir Goldstein <firstname.lastname@example.org>,
Antonio SJ Musumeci <email@example.com>,
David Anderson <firstname.lastname@example.org>,
Giuseppe Scrivano <email@example.com>,
Jann Horn <firstname.lastname@example.org>, Jens Axboe <email@example.com>,
Martijn Coenen <firstname.lastname@example.org>,
Palmer Dabbelt <email@example.com>,
Paul Lawrence <firstname.lastname@example.org>,
Stefano Duo <email@example.com>,
Zimuzo Ezeozue <firstname.lastname@example.org>,
Subject: Re: [PATCH V9 1/4] fuse: Definitions and ioctl() for passthrough
Date: Thu, 22 Oct 2020 17:12:54 +0100 [thread overview]
Message-ID: <20201022161254.GA36774@google.com> (raw)
On Wed, Sep 30, 2020 at 05:44:54PM +0200, Miklos Szeredi wrote:
> On Thu, Sep 24, 2020 at 3:13 PM Alessio Balsini <email@example.com> wrote:
> > Introduce the new FUSE passthrough ioctl(), which allows userspace to
> > specify a direct connection between a FUSE file and a lower file system
> > file.
> > Such ioctl() requires userspace to specify:
> > - the file descriptor of one of its opened files,
> > - the unique identifier of the FUSE request associated with a pending
> > open/create operation,
> > both encapsulated into a fuse_passthrough_out data structure.
> > The ioctl() will search for the pending FUSE request matching the unique
> > identifier, and update the passthrough file pointer of the request with the
> > file pointer referenced by the passed file descriptor.
> > When that pending FUSE request is handled, the passthrough file pointer
> > is copied to the fuse_file data structure, so that the link between FUSE
> > and lower file system is consolidated.
> How about returning an ID from the ioctl (like the fuse2 porototype)
> and returning that in fuse_open_out.passthrough_fh?
> Seems a more straightforward interface to me.
With this patch I tried to avoid any API modifications, for example,
changing fuse_open_out, doing everything at ioctl() time, and limiting the
allocation of dynamic memory.
In my next patch set (that I'll share as soon as I have enough hours of
testing with syzkaller) I implemented something similar to fuse2 in terms
of communication between kernel and userspace, with an id passing as you
recommended. So, userspace gets an id from the ioctl() and sends it back to
the kernel through the open/create reply, setting the passthrough_fh field
in fuse_open_out, that originally was the uint32_t padding. This wouldn't
change the fuse_open_out struct size, but is kind of an API breakage.
As in fuse2 I'm using IDR to generate the id and track the passthrough
entry information. On the other hand, compared to fuse2, I have one dynamic
IDR for each fuse_conn to prevent the owner of a connection from messing
with the ids of others.
In the upcoming patch set, the elements of each IDR serve the only purpose
of keeping track of the id in the timespan between the ioctl() and the
open/create reply. That IDR entry is removed right after the open/create
request is completed.
If in fuse2 the global IDR is queried for every read/write operation, my
new patch set would still create a "passthrough entry" for each fuse_file
to simplify the access to the lower file system at every read/write,
getting rid of IDR searches for each read/write operation.
Does this solution make sense?
I'm not sure that the upcoming solution is simpler than this one, but for
sure it keeps the interface more flexible and I like that it is moving in
the direction of fuse2.
next prev parent reply other threads:[~2020-10-22 16:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-24 13:13 [PATCH V9 0/4] fuse: Add support for passthrough read/write Alessio Balsini
2020-09-24 13:13 ` [PATCH V9 1/4] fuse: Definitions and ioctl() for passthrough Alessio Balsini
2020-09-29 14:37 ` Alessio Balsini
2020-09-30 15:44 ` Miklos Szeredi
2020-10-22 16:12 ` Alessio Balsini [this message]
2020-09-24 13:13 ` [PATCH V9 2/4] fuse: Trace daemon creds Alessio Balsini
2020-09-30 18:45 ` Miklos Szeredi
2020-09-30 19:16 ` Antonio SJ Musumeci
2020-10-22 16:14 ` Alessio Balsini
2020-09-24 13:13 ` [PATCH V9 3/4] fuse: Introduce synchronous read and write for passthrough Alessio Balsini
2020-09-30 18:50 ` Miklos Szeredi
2020-10-22 16:17 ` Alessio Balsini
2020-09-24 13:13 ` [PATCH V9 4/4] fuse: Handle asynchronous read and write in passthrough Alessio Balsini
2020-09-30 18:54 ` Miklos Szeredi
2020-10-22 16:38 ` Alessio Balsini
2020-09-30 15:33 ` [PATCH V9 0/4] fuse: Add support for passthrough read/write Miklos Szeredi
2020-10-02 13:38 ` Alessio Balsini
2020-10-21 15:39 ` Alessio Balsini
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH V9 1/4] fuse: Definitions and ioctl() for passthrough' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).