linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Olga Kornievskaia <olga.kornievskaia@gmail.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jeff Layton <jlayton@redhat.com>,
	willy@infradead.org, viro@zeniv.linux.org.uk,
	linux-fsdevel@vger.kernel.org,
	linux-nfs <linux-nfs@vger.kernel.org>,
	fweimer@redhat.com, Steve French <smfrench@gmail.com>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	Christoph Hellwig <hch@lst.de>,
	Linux API <linux-api@vger.kernel.org>
Subject: Re: [PATCH v1 02/11] VFS permit cross device vfs_copy_file_range
Date: Thu, 25 Oct 2018 11:58:52 -0400	[thread overview]
Message-ID: <CAN-5tyGpp15S34b4OUEyO6p+7KAn61xQAF-ozMoBi6PKh1fC2g@mail.gmail.com> (raw)
In-Reply-To: <CAOQ4uxgW+AAxGszy=rsNCZLAJPpJbz6O4Xtnje-=WeDo+oATag@mail.gmail.com>

On Thu, Oct 25, 2018 at 12:59 AM Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Wed, Oct 24, 2018 at 10:59 PM Olga Kornievskaia
> <olga.kornievskaia@gmail.com> wrote:
> >
> [...]
> > It feels like folks are now ok with either the check being in the
> > drivers or doing the check in the VFS layer.
> >
> > I'm picking the choice of not doing the check in the VFS layer because
> > it allows for do_splice_direct() by any caller.
>
> I'm sorry, but this reasoning in flawed and this is not the reason that
> Matthew promoted not doing same fs type check in vfs.

I stated the reason why I picked to do the check at the driver layer.
Looking at your version of the sb type check to be only applied to the
copy_file_range indeed makes my argument invalid. I was under the
impression that sb type check was being proposed as a standalone check
(just like the sb check was standalone). Thus, yes I didn't completely
understand what you proposed.

> You did not understand the option that I was promoting to begin with.
> What I suggested was:
>
> 1. Remove current same sb check in beginning of vfs_copy_file_range()
> 2. Check sb && ->clone_file_range
> 3. Check same sb type && ->copy_file_range
> 4. Cross fs do_splice_direct()
>
> It's fine that you chose not to check for same fs type in VFS before calling
> copy_file_range() method, but still requires an ACK from Al that he agrees
> with passing in file * of another filesystem on the interface.

Al, can you please provide a final decision as to which way you would
prefer for this to be done.

> > I'm about to submit
> > the new version of the patches (this time I will include the NFS patch
> > series). We can continue with the discussion on the new version.
> >
> > I have added checks for the CIFS and OverlayFS to be consistent with
> > the previous behavior -- no cross-device copy_offload, I assume if and
> > when those file systems are ready to make use of it they'll remove the
> > check.
> >
>
> Actually overlayfs code is "ready" for cross sb copy, but neither nfs nor
> cifs are supported as upper file system, so it doesn't matter much.

So then the commit statement is still true. When overlayfs will have
upper file systems that do support it, this check can be removed.

>
> Thanks,
> Amir.

  reply	other threads:[~2018-10-26  0:32 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-19 15:30 [PATCH v1 01/11] fs: Don't copy beyond the end of the file Olga Kornievskaia
2018-10-19 15:30 ` [PATCH v1 02/11] VFS permit cross device vfs_copy_file_range Olga Kornievskaia
2018-10-19 15:54   ` Amir Goldstein
2018-10-19 16:14     ` Amir Goldstein
2018-10-19 17:44       ` Matthew Wilcox
2018-10-19 17:58         ` Amir Goldstein
2018-10-19 16:24     ` Olga Kornievskaia
2018-10-19 17:04       ` Olga Kornievskaia
2018-10-20  1:37       ` Steve French
2018-10-19 17:58   ` Matthew Wilcox
2018-10-19 18:47     ` Olga Kornievskaia
2018-10-19 19:06       ` Matthew Wilcox
2018-10-21 13:01         ` Jeff Layton
2018-10-22 18:39         ` Olga Kornievskaia
2018-10-21 14:10     ` Jeff Layton
2018-10-20  4:05   ` Al Viro
2018-10-20  8:54     ` Amir Goldstein
2018-10-22 18:45       ` Olga Kornievskaia
2018-10-22 19:06         ` Matthew Wilcox
2018-10-22 19:34           ` Olga Kornievskaia
2018-10-22 19:48             ` Amir Goldstein
2018-10-22 20:29               ` Matthew Wilcox
2018-10-22 23:39             ` Jeff Layton
2018-10-23  6:05               ` Amir Goldstein
2018-10-23 15:03                 ` Olga Kornievskaia
2018-10-23 15:30                   ` Olga Kornievskaia
2018-10-23 17:16                     ` Olga Kornievskaia
2018-10-24 11:17                       ` Jeff Layton
2018-10-24 19:59                         ` Olga Kornievskaia
2018-10-25  4:58                           ` Amir Goldstein
2018-10-25 15:58                             ` Olga Kornievskaia [this message]
2018-10-25 16:00                               ` Olga Kornievskaia
2018-10-25 16:57                                 ` Amir Goldstein
2018-10-23 15:39                   ` Matthew Wilcox
2018-10-24 11:32                     ` Amir Goldstein
     [not found] <20181019152932.32462-1-olga.kornievskaia@gmail.com>
     [not found] ` <20181019152932.32462-3-olga.kornievskaia@gmail.com>
2018-10-19 16:14   ` Trond Myklebust
2018-10-19 16:26     ` Olga Kornievskaia

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=CAN-5tyGpp15S34b4OUEyO6p+7KAn61xQAF-ozMoBi6PKh1fC2g@mail.gmail.com \
    --to=olga.kornievskaia@gmail.com \
    --cc=amir73il@gmail.com \
    --cc=darrick.wong@oracle.com \
    --cc=fweimer@redhat.com \
    --cc=hch@lst.de \
    --cc=jlayton@redhat.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=smfrench@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    /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).