Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp7226109pxb; Thu, 18 Feb 2021 05:03:21 -0800 (PST) X-Google-Smtp-Source: ABdhPJw/W6OrLCLF3NqwHvdeRgU0t7U85tEstHZSG6qpQ/zs8JQs5VoHrRQSk6kUWYNSnPP0b3EG X-Received: by 2002:a05:6402:1b01:: with SMTP id by1mr3989579edb.61.1613653399402; Thu, 18 Feb 2021 05:03:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613653399; cv=none; d=google.com; s=arc-20160816; b=vfnnrxd3LKUlRVNbZaKSI3LtBcWD5HQdb6mt0gjHiOfIuvz7wWeT23xd2g2855LFed Jc0mO+Xqle6Ld2oSNoJBnT75KqYIa71fP39XAfMMIBKLBdn4BGWPNxrxzwO+Bxlm89MA Vyg4WD3MySaO9em6hbA/qJW90p91X7NXvcA4OTpIr69BfTw1US1UMDzW6zJ5yBniruBL gDk/hPqVzWlXBMcmqaDhZuvlRwp92LlJQmPQjhD7rh1EclSqqhHD2/RGvQfWZva5GSPG kn1EBMT0hMJF0dpKTfLaNstpkGK+nKF1cOk3BlG0GNaQbyUPRk+dTU3kJd5ye2jtNfWb m43A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:in-reply-to:date :references:subject:cc:to:from; bh=L5/qYwP3dn9O1sRkSj8sxdfpRekXeV/VOr4PS4x7v90=; b=FyP8qzaR9Lc/vNWAiAuVsoD4pGZgsJoxTQS0TWEALxedDvWkPff+RM1Nfrf65X2KkR Nh69m/T0pIYRxEo+oiKkkB9rZjJfDXX1dVsSjlMMWP/qRlKXJK6KZMr8qcABumkhyWV9 wL2Y994tY0SPVfWTfIsj1wtZyrjXMtgZ5eSvjVDCNRB51QPK+wLdh4ecSId6DUVz+xjp T84d1V2DNr9IQOjWXRgCMHnI4/EZUk8pCV/xDQWSGKx/6vvj1o2tiSuxdXfX2oU4nWOF MH2rIU6UZvoAr5LxFX4RYs32fimPffZ50mo8XsOTwJMqIvKcDuQvEa1KO4Ixpf7o1JAX gaYQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id co9si3432096edb.555.2021.02.18.05.02.45; Thu, 18 Feb 2021 05:03:19 -0800 (PST) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232917AbhBRM4N (ORCPT + 99 others); Thu, 18 Feb 2021 07:56:13 -0500 Received: from mx2.suse.de ([195.135.220.15]:41568 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231915AbhBRMPP (ORCPT ); Thu, 18 Feb 2021 07:15:15 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 121FCACE5; Thu, 18 Feb 2021 12:14:06 +0000 (UTC) Received: from localhost (brahms [local]) by brahms (OpenSMTPD) with ESMTPA id e471242a; Thu, 18 Feb 2021 12:15:08 +0000 (UTC) From: Luis Henriques To: Amir Goldstein Cc: Christoph Hellwig , Jeff Layton , Steve French , Miklos Szeredi , Trond Myklebust , Anna Schumaker , Alexander Viro , "Darrick J. Wong" , Dave Chinner , Greg KH , Nicolas Boichat , Ian Lance Taylor , Luis Lozano , ceph-devel , linux-kernel , CIFS , samba-technical , linux-fsdevel , Linux NFS Mailing List Subject: Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices References: <20210215154317.8590-1-lhenriques@suse.de> <20210218074207.GA329605@infradead.org> <87v9apis97.fsf@suse.de> Date: Thu, 18 Feb 2021 12:15:08 +0000 In-Reply-To: <87v9apis97.fsf@suse.de> (Luis Henriques's message of "Thu, 18 Feb 2021 10:29:08 +0000") Message-ID: <87mtw1incj.fsf@suse.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org Luis Henriques writes: > Amir Goldstein writes: > >> On Thu, Feb 18, 2021 at 9:42 AM Christoph Hellwig wrote: >>> >>> Looks good: >>> >>> Reviewed-by: Christoph Hellwig >>> >>> This whole idea of cross-device copie has always been a horrible idea, >>> and I've been arguing against it since the patches were posted. >> >> Ok. I'm good with this v2 as well, but need to add the fallback to >> do_splice_direct() >> in nfsd_copy_file_range(), because this patch breaks it. >> >> And the commit message of v3 is better in describing the reported issue. > > Except that, as I said in a previous email, v2 doesn't really fix the > issue: all the checks need to be done earlier in generic_copy_file_checks(). > > I'll work on getting v4, based on v2 and but moving the checks and > implementing your review suggestions to v3 (plus this nfs change). There's something else: The filesystems (nfs, ceph, cifs, fuse) rely on the fallback to generic_copy_file_range() if something's wrong. And this "something's wrong" is fs specific. For example: in ceph it is possible to offload the file copy to the OSDs even if the files are in different filesystems as long as these filesystems are on the *same* ceph cluster. If the copy being done is across two different clusters, then the copy reverts to splice. This means that the boilerplate code being removed in v2 of this patch needs to be restored and replace by: ret = __ceph_copy_file_range(src_file, src_off, dst_file, dst_off, len, flags); if (ret == -EOPNOTSUPP || ret == -EXDEV) ret = do_splice_direct(src_file, &src_off, dst_file, &dst_off, len > MAX_RW_COUNT ? MAX_RW_COUNT : len, flags); return ret; A quick look at the other filesystems code indicate similar patterns. Since at this point we've gone through all the syscall checks already, calling do_splice_direct() shouldn't be a huge change. But I may be missing something. Again. Which is quite likely :-) Cheers, -- Luis