From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ipmail03.adl6.internode.on.net ([150.101.137.143]:20684 "EHLO ipmail03.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725736AbeLBJOW (ORCPT ); Sun, 2 Dec 2018 04:14:22 -0500 Date: Sun, 2 Dec 2018 09:00:45 +1100 From: Dave Chinner To: Amir Goldstein Cc: Olga Kornievskaia , bfields@redhat.com, Linux NFS Mailing List , linux-fsdevel , Matthew Wilcox , Jeff Layton , Steve French Subject: Re: [PATCH v2 01/10] VFS generic copy_file_range() support Message-ID: <20181201220045.GQ19305@dastard> References: <20181130200348.59524-1-olga.kornievskaia@gmail.com> <20181130200348.59524-2-olga.kornievskaia@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sat, Dec 01, 2018 at 10:11:48AM +0200, Amir Goldstein wrote: > On Fri, Nov 30, 2018 at 10:04 PM Olga Kornievskaia > wrote: > > > > Relax the condition that input files must be from the same > > file systems. > > > > Add checks that input parameters adhere semantics. > > > > If no copy_file_range() support is found, then do generic > > checks for the unsupported page cache ranges, LFS, limits, > > and clear setuid/setgid if not running as root before calling > > do_splice_direct(). Update atime,ctime,mtime afterwards. > > > > Signed-off-by: Olga Kornievskaia > > --- > > This patch is either going to bring you down or make you stronger ;-) > > This is not how its done. Behavior change and refactoring mixed into > one patch is wrong for several reasons. And when you relax same sb > check you need to restrict it inside filesystems, like your previous patch > did. ..... > In any case, I hear that Dave is neck deep in fixing copy_file_range() > so changes to this function should be collaborated with him. Or better > yet, wait until he posts his fixes and carry on from there. Yeah, because I've heard nothing for a month and this is kinda important, I have a series of 8-9 patches that make all the fixes we need, push the cross-filesystem checks down into the filesystems, and let filesystems handle the fallback to a splice based copy themselves (because there are way more fallback cases than just EOPNOPSUPP and EXDEV). I also have a patch for the man page that document all the missing failure cases, and document where things are filesystem specific or not. And I also have a fstests patch that exercises all the failure cases so that all filesystems will end up behaving the same way for all the same cases they should. I'm still sorting out the fstests patch (it requires changes to xfs_io's copy-range command) so I've got some confidence that the code actually does what it says in the man page, but I should have that sorted in a couple of days. Cheers, Dave. -- Dave Chinner david@fromorbit.com