Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp5068012pxb; Mon, 15 Feb 2021 08:40:03 -0800 (PST) X-Google-Smtp-Source: ABdhPJziGZ5CkiJsS7FjcHSLeC23UkYdY/0igRuLd7PfoapBC7Q1/pdczUeWxM8M4rtPCcVnReuC X-Received: by 2002:a17:906:8287:: with SMTP id h7mr8850689ejx.222.1613407202812; Mon, 15 Feb 2021 08:40:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613407202; cv=none; d=google.com; s=arc-20160816; b=msu6G+lwgOppG5C8iBQ/ML3sL2XLkdM/eseELqRiCGmWveDAzpeLgDSCretVB6AWTC IGpcjsPahNK3GW7ujitaO8lqsvEAs6UBDgtljxlKfRvNIKRCM29J+coyZ4z/thvVmwRC eCXE2tz/3obB1Um6PERK2zo2GaaNtc10I/iwk9bN1lylW5PEF2rfsIw7T5+EI5R/80nq cFiPmmHL6GM0vm8G0Si9LBkiwdAIl1Etv7C00xwGf+9G2V4sUqjrITD+4EYWIgXMPMaM wDVcOaBTxQsv9aVBOLrA+lAlbzIY01XrmPVaMAJN7+cglVmPE+ZK2427PyasK4FdjXEF JG0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=p99Y0IizcDgJJyFvLWYBqAWdhmLE2nZ89U026tr0eGg=; b=GwqigoYTE17N97pMAYb1snnstbvNrDGjGdnXl25J06z8uIIk8SnSGowQTmnuaqWN4q isnPucXyze/DjKKCIaa9L4bNNWWKXVstpQMimv2LgMakwG843+d72yqCXVRpss++l94O r1gS0honac1DM8GkEl/83TDd2BJ+ZRdnr3LxqyP/f66OIcDu9jP9L/Cfwa06CyWB8SRI x9601J7PVVSY+wdYAL4lPWbEvimxL0qamaQVR6xf0v9NCs68kb/9Ul9z0Zo2nuNiDTI6 Gb/0t2qp1YYUAL3+e1Jj1pzAwRCMuGMglKIBAEPxiQ7qTR8NYQRH1/ojbXYrhF0S7C3n uNQA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=EJw3TQMa; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m3si13310896edq.484.2021.02.15.08.39.36; Mon, 15 Feb 2021 08:40:02 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=EJw3TQMa; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231196AbhBOQij (ORCPT + 99 others); Mon, 15 Feb 2021 11:38:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52684 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231259AbhBOQfw (ORCPT ); Mon, 15 Feb 2021 11:35:52 -0500 Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 63925C061756; Mon, 15 Feb 2021 08:35:09 -0800 (PST) Received: by mail-il1-x12a.google.com with SMTP id w1so5918984ilm.12; Mon, 15 Feb 2021 08:35:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p99Y0IizcDgJJyFvLWYBqAWdhmLE2nZ89U026tr0eGg=; b=EJw3TQMaTEgxG+xxenxwXWMqxKo4ZoBtUH2h4FwcOqRV6/QtYGQwBEBxvsJv15bnRc dvDPXT3Focve5ZfHuEATmhmZ2qzU8sbTrBJQ5IYViyNEfynKOwg9B7zfkwXWrocyYEKe SREkY7xE+EDu0qcbWsJOXZVuN7YujE+MZniihDK+rPTt0Sasao93PZ7/aUm4d6Het5tp Fh/EbSCks8NdGW17iC3KMWuCTrbtzrh7zTUnPC7IHGnSQ23voOYv10qLj4Dp8EeHfjX2 yJh0qkO7VsWTk9dpgx/i4a8qr6th45vFOn4lkildCUxVzOO1yRu6xCElWYoMYXSmWLGv cjPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p99Y0IizcDgJJyFvLWYBqAWdhmLE2nZ89U026tr0eGg=; b=QoL0AZSuEoen1k5PgAHVTv2sIFB4/ca/NYFVvQ/ne8kAWkQtvSZIxM4aF9a+GW4ubB QtLwaFMdpLslfB0XMTriEHO5FsO4bXC+gIJNAuORlEde+jrWIR+GcUavXkp8J090D/k1 0Z5GzG1z0ah4uQPmTFNsT7XuCx+HdDjHgsspWTTi1ewPuDv7vveQTxgv5hW7A9wzWaJ3 N4EYzD/A3F+T6IcP55oDAFe759P72VGuseMvNztTXx6zP8GdZhrcunRL+jfRUzTOpnCn 35d8uv/Czf7hKy0LvD+MZUARhpLHFFuYL2VYSCwiVAxEQnGAnLAsFksFSKIpGCXqggui Ppkw== X-Gm-Message-State: AOAM5314nj75Aa8qTD0OgA572l/MLe6o4tWLw41R+RYlc7pYsMNlAqpm l+B2nEzf3M0+0O6um1f3r+ydZ+hXfTXEbwu688w= X-Received: by 2002:a92:2c08:: with SMTP id t8mr13060037ile.72.1613406908904; Mon, 15 Feb 2021 08:35:08 -0800 (PST) MIME-Version: 1.0 References: <20210215154317.8590-1-lhenriques@suse.de> In-Reply-To: <20210215154317.8590-1-lhenriques@suse.de> From: Amir Goldstein Date: Mon, 15 Feb 2021 18:34:57 +0200 Message-ID: Subject: Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices To: Luis Henriques Cc: 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Mon, Feb 15, 2021 at 5:42 PM Luis Henriques wrote: > > Nicolas Boichat reported an issue when trying to use the copy_file_range > syscall on a tracefs file. It failed silently because the file content is > generated on-the-fly (reporting a size of zero) and copy_file_range needs > to know in advance how much data is present. > > This commit restores the cross-fs restrictions that existed prior to > 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") and > removes generic_copy_file_range() calls from ceph, cifs, fuse, and nfs. > > Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") > Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/ > Cc: Nicolas Boichat > Signed-off-by: Luis Henriques Code looks ok. You may add: Reviewed-by: Amir Goldstein I agree with Trond that the first paragraph of the commit message could be improved. The purpose of this change is to fix the change of behavior that caused the regression. Before v5.3, behavior was -EXDEV and userspace could fallback to read. After v5.3, behavior is zero size copy. It does not matter so much what makes sense for CFR to do in this case (generic cross-fs copy). What matters is that nobody asked for this change and that it caused problems. Thanks, Amir.