From: Amir Goldstein <amir73il@gmail.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
Alessio Balsini <balsini@android.com>,
Peng Tao <bergwolf@gmail.com>,
Akilesh Kailash <akailash@google.com>,
Antonio SJ Musumeci <trapexit@spawn.link>,
David Anderson <dvander@google.com>,
Giuseppe Scrivano <gscrivan@redhat.com>,
Jann Horn <jannh@google.com>, Jens Axboe <axboe@kernel.dk>,
Martijn Coenen <maco@android.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Lawrence <paullawrence@google.com>,
Stefano Duo <duostefano93@gmail.com>,
Zimuzo Ezeozue <zezeozue@google.com>, wuyan <wu-yan@tcl.com>,
fuse-devel <fuse-devel@lists.sourceforge.net>,
kernel-team <kernel-team@android.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH RESEND V12 3/8] fuse: Definitions and ioctl for passthrough
Date: Mon, 15 May 2023 17:00:16 +0300 [thread overview]
Message-ID: <CAOQ4uxjrhf8D081Z8aG71=Kjjub28MwR3xsaAHD4cK48-FzjNA@mail.gmail.com> (raw)
In-Reply-To: <CAJfpegv1ByQg750uHTGOTZ7CJ4OrYp6i4MKXU13mwZPUEk+pnA@mail.gmail.com>
On Mon, May 15, 2023 at 10:29 AM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Fri, 12 May 2023 at 21:37, Amir Goldstein <amir73il@gmail.com> wrote:
>
> > I was waiting for LSFMM to see if and how FUSE-BPF intends to
> > address the highest value use case of read/write passthrough.
> >
> > From what I've seen, you are still taking a very broad approach of
> > all-or-nothing which still has a lot of core design issues to address,
> > while these old patches already address the most important use case
> > of read/write passthrough of fd without any of the core issues
> > (credentials, hidden fds).
> >
> > As far as I can tell, this old implementation is mostly independent of your
> > lookup based approach - they share the low level read/write passthrough
> > functions but not much more than that, so merging them should not be
> > a blocker to your efforts in the longer run.
> > Please correct me if I am wrong.
> >
> > As things stand, I intend to re-post these old patches with mandatory
> > FOPEN_PASSTHROUGH_AUTOCLOSE to eliminate the open
> > questions about managing mappings.
> >
> > Miklos, please stop me if I missed something and if you do not
> > think that these two approaches are independent.
>
> Do you mean that the BPF patches should use their own passthrough mechanism?
>
> I think it would be better if we could agree on a common interface for
> passthough (or per Paul's suggestion: backing) mechanism.
Well, not exactly different.
With BFP patches, if you have a backing inode that was established during
LOOKUP with rules to do passthrough for open(), you'd get a backing file and
that backing file would be used to passthrough read/write.
FOPEN_PASSTHROUGH is another way to configure passthrough read/write
to a backing file that is controlled by the server per open fd instead of by BFP
for every open of the backing inode.
Obviously, both methods would use the same backing_file field and
same read/write passthrough methods regardless of how the backing file
was setup.
Obviously, the BFP patches will not use the same ioctl to setup passthrough
(and/or BPF program) to a backing inode, but I don't think that matters much.
When we settle on ioctls for setting up backing inodes, we can also add new
ioctls for setting up backing file with optional BPF program.
I don't see any reason to make the first ioctl more complicated than this:
struct fuse_passthrough_out {
uint32_t fd;
/* For future implementation */
uint32_t len;
void *vec;
};
One advantage with starting with FOPEN_PASSTHROUGH, besides
dealing with the highest priority performance issue, is how it deals with
resource limits on open files.
While the backing files are not accounted to the server, the server
is very likely to keep an open fd for the backing file until release,
otherwise, the server will not be able to perform other non-passthrough
file operations (e.g. fallocate) on the backing fd, so at least with
FOPEN_PASSTHROUGH_AUTOCLOSE, there should be only
up to 2 times the number of open files, very much the same as overlayfs.
I intend to enforce this heuristically by counting the number of passthrough
fds and restrict new passthrough fd setup to the number of current open fds
by the server, so a malicious or misbehaving server cannot setup infinite
number of backing fds that it does not also keep open itself.
>
> Let's see this patchset and then we can discuss how this could be
> usable for the BPF case as well.
>
OK. I'll try to dust off these patches and re-submit.
Thanks,
Amir.
next prev parent reply other threads:[~2023-05-15 14:00 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-25 15:30 [PATCH RESEND V12 0/8] fuse: Add support for passthrough read/write Alessio Balsini
2021-01-25 15:30 ` [PATCH RESEND V12 1/8] fs: Generic function to convert iocb to rw flags Alessio Balsini
2021-01-25 16:46 ` Alessio Balsini
2021-03-24 7:43 ` Rokudo Yan
2021-03-24 14:02 ` Alessio Balsini
2021-01-25 15:30 ` [PATCH RESEND V12 2/8] fuse: 32-bit user space ioctl compat for fuse device Alessio Balsini
[not found] ` <CAMAHBGzkfEd9-1u0iKXp65ReJQgUi_=4sMpmfkwEOaMp6Ux7pg@mail.gmail.com>
2021-01-27 13:40 ` Alessio Balsini
[not found] ` <CAMAHBGwpKW+30kNQ_Apt8A-FTmr94hBOzkT21cjEHHW+t7yUMQ@mail.gmail.com>
2021-01-28 14:15 ` Alessio Balsini
2021-02-05 9:54 ` Peng Tao
2021-03-16 18:57 ` Arnd Bergmann
2021-02-17 10:21 ` Miklos Szeredi
2021-03-01 12:26 ` Alessio Balsini
2021-03-16 18:53 ` Arnd Bergmann
2021-03-18 16:13 ` Alessio Balsini
2021-03-18 21:15 ` Arnd Bergmann
2021-03-19 15:21 ` Alessio Balsini
2021-01-25 15:30 ` [PATCH RESEND V12 3/8] fuse: Definitions and ioctl for passthrough Alessio Balsini
2021-02-17 13:41 ` Miklos Szeredi
2021-02-19 7:05 ` Peng Tao
2021-02-19 8:40 ` Miklos Szeredi
2021-03-01 17:05 ` Alessio Balsini
2022-09-08 15:36 ` Amir Goldstein
2022-09-09 19:07 ` Miklos Szeredi
2022-09-10 8:52 ` Amir Goldstein
2022-09-10 13:03 ` Bernd Schubert
2022-09-12 9:29 ` Miklos Szeredi
2022-09-12 12:29 ` Amir Goldstein
2022-09-12 13:03 ` Miklos Szeredi
2022-09-12 13:05 ` Miklos Szeredi
2022-09-12 13:26 ` Amir Goldstein
2022-09-12 14:22 ` Miklos Szeredi
2022-09-12 15:39 ` Amir Goldstein
2022-09-12 17:43 ` Hao Luo
2022-09-12 18:28 ` Overlayfs with writable lower layer Amir Goldstein
2022-09-13 18:26 ` Hao Luo
2022-09-13 18:54 ` Amir Goldstein
2022-09-13 20:33 ` Hao Luo
2022-09-14 3:46 ` Amir Goldstein
2022-09-14 18:00 ` Hao Luo
2022-09-14 19:23 ` Amir Goldstein
2022-09-14 19:33 ` Hao Luo
2022-09-15 10:54 ` Amir Goldstein
2023-05-12 19:37 ` [PATCH RESEND V12 3/8] fuse: Definitions and ioctl for passthrough Amir Goldstein
2023-05-15 7:29 ` Miklos Szeredi
2023-05-15 14:00 ` Amir Goldstein [this message]
2023-05-15 20:16 ` [fuse-devel] " Nikolaus Rath
2023-05-15 21:11 ` Bernd Schubert
2023-05-15 21:45 ` Paul Lawrence
2023-05-16 8:43 ` Miklos Szeredi
2023-05-16 10:16 ` Nikolaus Rath
2023-05-16 8:48 ` Amir Goldstein
2021-01-25 15:30 ` [PATCH RESEND V12 4/8] fuse: Passthrough initialization and release Alessio Balsini
2021-02-17 13:52 ` Miklos Szeredi
2021-05-05 12:21 ` Amir Goldstein
2021-05-17 11:36 ` Alessio Balsini
2021-05-17 13:21 ` Amir Goldstein
2021-01-25 15:30 ` [PATCH RESEND V12 5/8] fuse: Introduce synchronous read and write for passthrough Alessio Balsini
2021-02-17 14:00 ` Miklos Szeredi
2021-01-25 15:30 ` [PATCH RESEND V12 6/8] fuse: Handle asynchronous read and write in passthrough Alessio Balsini
2021-01-25 15:30 ` [PATCH RESEND V12 7/8] fuse: Use daemon creds in passthrough mode Alessio Balsini
2021-02-05 9:23 ` Peng Tao
2021-02-05 11:21 ` Alessio Balsini
2021-01-25 15:30 ` [PATCH RESEND V12 8/8] fuse: Introduce passthrough for mmap Alessio Balsini
2021-02-17 14:05 ` Miklos Szeredi
2021-04-01 11:24 ` Alessio Balsini
2021-11-18 18:31 ` [PATCH RESEND V12 0/8] fuse: Add support for passthrough read/write Amir Goldstein
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAOQ4uxjrhf8D081Z8aG71=Kjjub28MwR3xsaAHD4cK48-FzjNA@mail.gmail.com' \
--to=amir73il@gmail.com \
--cc=akailash@google.com \
--cc=axboe@kernel.dk \
--cc=balsini@android.com \
--cc=bergwolf@gmail.com \
--cc=daniel@iogearbox.net \
--cc=duostefano93@gmail.com \
--cc=dvander@google.com \
--cc=fuse-devel@lists.sourceforge.net \
--cc=gscrivan@redhat.com \
--cc=jannh@google.com \
--cc=kernel-team@android.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=maco@android.com \
--cc=miklos@szeredi.hu \
--cc=palmer@dabbelt.com \
--cc=paullawrence@google.com \
--cc=trapexit@spawn.link \
--cc=wu-yan@tcl.com \
--cc=zezeozue@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 read-only IMAP folder(s) and NNTP newsgroup(s).