Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Alessio Balsini <balsini@android.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	Akilesh Kailash <akailash@google.com>,
	David Anderson <dvander@google.com>,
	Eric Yan <eric.yan@oneplus.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 <stefanoduo@google.com>,
	Zimuzo Ezeozue <zezeozue@google.com>,
	fuse-devel <fuse-devel@lists.sourceforge.net>,
	kernel-team <kernel-team@android.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V8 2/3] fuse: Introduce synchronous read and write for passthrough
Date: Mon, 21 Sep 2020 16:07:56 +0300	[thread overview]
Message-ID: <CAOQ4uxhA+6+m0GTWiaRLC090FCngVYHJv62TCPNNSWzVkdQjgg@mail.gmail.com> (raw)
In-Reply-To: <20200921110156.GC3385065@google.com>

On Mon, Sep 21, 2020 at 2:01 PM Alessio Balsini <balsini@android.com> wrote:
>
> Hi Amir,
>
> On Sat, Sep 12, 2020 at 12:55:35PM +0300, Amir Goldstein wrote:
> > On Fri, Sep 11, 2020 at 7:34 PM Alessio Balsini <balsini@android.com> wrote:
> > > +ssize_t fuse_passthrough_read_iter(struct kiocb *iocb_fuse,
> > > +                                  struct iov_iter *iter)
> > > +{
> > > +       ssize_t ret;
> > > +       struct file *fuse_filp = iocb_fuse->ki_filp;
> > > +       struct fuse_file *ff = fuse_filp->private_data;
> > > +       struct file *passthrough_filp = ff->passthrough_filp;
> > > +
> > > +       if (!iov_iter_count(iter))
> > > +               return 0;
> > > +
> > > +       if (is_sync_kiocb(iocb_fuse)) {
> > > +               struct kiocb iocb;
> > > +
> > > +               kiocb_clone(&iocb, iocb_fuse, passthrough_filp);
> > > +               ret = call_read_iter(passthrough_filp, &iocb, iter);
> > > +               iocb_fuse->ki_pos = iocb.ki_pos;
> > > +               if (ret >= 0)
> > > +                       fuse_copyattr(fuse_filp, passthrough_filp, false);
> > > +
> > > +       } else {
> > > +               ret = -EIO;
> > > +       }
> > > +
> > > +       return ret;
> > > +}
> > > +
> > > +ssize_t fuse_passthrough_write_iter(struct kiocb *iocb_fuse,
> > > +                                   struct iov_iter *iter)
> > > +{
> > > +       ssize_t ret;
> > > +       struct file *fuse_filp = iocb_fuse->ki_filp;
> > > +       struct fuse_file *ff = fuse_filp->private_data;
> > > +       struct inode *fuse_inode = file_inode(fuse_filp);
> > > +       struct file *passthrough_filp = ff->passthrough_filp;
> > > +
> > > +       if (!iov_iter_count(iter))
> > > +               return 0;
> > > +
> > > +       inode_lock(fuse_inode);
> > > +
> > > +       if (is_sync_kiocb(iocb_fuse)) {
> > > +               struct kiocb iocb;
> > > +
> > > +               kiocb_clone(&iocb, iocb_fuse, passthrough_filp);
> > > +
> > > +               file_start_write(passthrough_filp);
> > > +               ret = call_write_iter(passthrough_filp, &iocb, iter);
> >
> > Why not vfs_iter_write()/vfs_iter_read()?
> >
> > You are bypassing many internal VFS checks that seem pretty important.
> >
>
> I've been thinking a lot about this and decided to go for the VFS bypassing
> solution because:
> 1. it looked odd to me to perform VFS checks twice, both for FUSE and lower
>    FS and it seemed to me that we found a tradeoff with Jann about doing
>    this lower FS call, and
> 2. in our Android use case (I just saw you asking for more details about
>    this in, I'll reply on the other thread), the user might have the right
>    credentials to access the FUSE file system, but not to access the lower
>    file system, so the VFS checkings would fail. So that would have created
>    the need for a credential bypassing that looked hacky.
>
> But I agree and I would probably sleep better knowing that VFS checks are
> not skipped :) So I decided to implemented the vfs_iter_{read,write}()
> variant.
>
> I again picked a lot from the overlayfs solution. In a few words, I get the
> FUSE daemon credential reference at FUSE FS creation time and, when
> passthrough read/write operations are triggered, the kernel temporarily
> overrides the requesting process' credentials with those of the FUSE
> daemon. Credentials are reverted as soon as the operation completes.
>
> I have a temporary development branch where I'm developing the V9 of this
> patch, plus the VFS variant (git history may change):
>
> https://github.com/balsini/linux/tree/fuse-passthrough-stable-v5.8-v9-vfs
>
> For now, I'm happy to say that I like this VFS solution, it also simplified
> the lower file system notifications, so I'll probably go with this in the
> V9.
>

I am happy this direction was workable, not because the overlayfs solution
is perfect, but because it already has decent mileage running into strange
corner cases and fixing them.

But I also think it is better when fuse driver performs actions on behalf
of the server, that it uses the server's credential, because this way,
the passthrough fd code path behaves logically closer to the non-passthrough
code, only (hopefully) faster.

Thanks,
Amir.

  reply	other threads:[~2020-09-21 13:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-11 16:34 [PATCH V8 0/3] fuse: Add support for passthrough read/write Alessio Balsini
2020-09-11 16:34 ` [PATCH V8 1/3] fuse: Definitions and ioctl() for passthrough Alessio Balsini
2020-09-12 11:06   ` Amir Goldstein
2020-09-18 16:33     ` Alessio Balsini
2020-09-18 19:59       ` Amir Goldstein
2020-09-22 12:15         ` Alessio Balsini
2020-09-22 16:08           ` Amir Goldstein
2020-09-29 14:30             ` Alessio Balsini
2020-09-11 16:34 ` [PATCH V8 2/3] fuse: Introduce synchronous read and write " Alessio Balsini
2020-09-12  9:55   ` Amir Goldstein
2020-09-21 11:01     ` Alessio Balsini
2020-09-21 13:07       ` Amir Goldstein [this message]
2020-09-11 16:34 ` [PATCH V8 3/3] fuse: Handle AIO read and write in passthrough Alessio Balsini
2020-09-11 17:23   ` Jens Axboe
2020-09-21 15:28     ` Alessio Balsini
2020-09-11 18:46 ` [fuse-devel] [PATCH V8 0/3] fuse: Add support for passthrough read/write Antonio SJ Musumeci
2020-09-18 16:03   ` Alessio Balsini

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=CAOQ4uxhA+6+m0GTWiaRLC090FCngVYHJv62TCPNNSWzVkdQjgg@mail.gmail.com \
    --to=amir73il@gmail.com \
    --cc=akailash@google.com \
    --cc=axboe@kernel.dk \
    --cc=balsini@android.com \
    --cc=dvander@google.com \
    --cc=eric.yan@oneplus.com \
    --cc=fuse-devel@lists.sourceforge.net \
    --cc=jannh@google.com \
    --cc=kernel-team@android.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maco@android.com \
    --cc=miklos@szeredi.hu \
    --cc=palmer@dabbelt.com \
    --cc=paullawrence@google.com \
    --cc=stefanoduo@google.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 NNTP newsgroup(s).