From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1F55FC433E6 for ; Thu, 18 Feb 2021 08:39:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B5B9C64E85 for ; Thu, 18 Feb 2021 08:39:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231326AbhBRIjh (ORCPT ); Thu, 18 Feb 2021 03:39:37 -0500 Received: from mail.kernel.org ([198.145.29.99]:38744 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231430AbhBRHjA (ORCPT ); Thu, 18 Feb 2021 02:39:00 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 4722D64DE0; Thu, 18 Feb 2021 07:34:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1613633693; bh=sjajRiTXns4+pD+gjYTsvSp91C0M53TJNj6vUwdi4zI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=nuuVLco0VtpvNqIZUSpPN0Ndt0DVjY30kFF+9i7jVsea7VCkByEQacOwl8C/FiWbo FAQIIojb/4410HMJVvN09W/dBS/mXtuK9ged/kDsSbarIJ8WOWygRjS6MWt6G9iLLX tPfsDE0sq+g/EQLfVZFTi7Ki/t5dWuwfstyBgdTw= Date: Thu, 18 Feb 2021 08:34:49 +0100 From: "gregkh@linuxfoundation.org" To: Andreas Dilger Cc: Amir Goldstein , Steve French , Anna Schumaker , Luis Henriques , Trond Myklebust , "samba-technical@lists.samba.org" , "drinkcat@chromium.org" , "iant@google.com" , "linux-cifs@vger.kernel.org" , "darrick.wong@oracle.com" , "linux-kernel@vger.kernel.org" , "jlayton@kernel.org" , "llozano@chromium.org" , "linux-nfs@vger.kernel.org" , "miklos@szeredi.hu" , "viro@zeniv.linux.org.uk" , "dchinner@redhat.com" , "linux-fsdevel@vger.kernel.org" , "sfrench@samba.org" , "ceph-devel@vger.kernel.org" Subject: Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices Message-ID: References: <87blckj75z.fsf@suse.de> <874kibkflh.fsf@suse.de> <216103D5-0575-4BFC-9802-2C21A1B12DF9@dilger.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <216103D5-0575-4BFC-9802-2C21A1B12DF9@dilger.ca> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 17, 2021 at 05:50:35PM -0700, Andreas Dilger wrote: > On Feb 17, 2021, at 1:08 AM, Amir Goldstein wrote: > > > > You are missing my point. > > Never mind which server. The server does not *need* to rely on > > vfs_copy_file_range() to copy files from XFS to ext4. > > The server is very capable of implementing the fallback generic copy > > in case source/target fs do not support native {copy,remap}_file_range(). > > > > w.r.t semantics of copy_file_range() syscall vs. the fallback to userespace > > 'cp' tool (check source file size before copy or not), please note that the > > semantics of CIFS_IOC_COPYCHUNK_FILE are that of the former: > > > > rc = cifs_file_copychunk_range(xid, src_file.file, 0, dst_file, 0, > > src_inode->i_size, 0); > > > > It will copy zero bytes if advertised source file size if zero. > > > > NFS server side copy semantics are currently de-facto the same > > because both the client and the server will have to pass through this > > line in vfs_copy_file_range(): > > > > if (len == 0) > > return 0; > > > > IMO, and this opinion was voiced by several other filesystem developers, > > the shortend copy semantics are the correct semantics for copy_file_range() > > syscall as well as for vfs_copy_file_range() for internal kernel users. > > > > I guess what this means is that if the 'cp' tool ever tries an opportunistic > > copy_file_range() syscall (e.g. --cfr=auto), it may result in zero size copy. > > Having a syscall that does the "wrong thing" when called on two files > doesn't make sense. Expecting userspace to check whether source/target > files supports CFR is also not practical. This is trivial for the > kernel to determine and return -EOPNOTSUPP to the caller if the source > file (procfs/sysfs/etc) does not work with CFR properly. How does the kernel "know" that a specific file in a specific filesystem will not work with CFR "properly"? That goes back to the original patch which tried to label each and every filesystem type with a "supported/not supported" type of flag, which was going to be a mess, especially as it seems that this might be a file-specific thing, not a filesystem-specific thing. The goal of the patch _should_ be that the kernel figure it out itself, but so far no one seems to be able to explain how that can be done :( So, any hints? thanks, greg k-h