Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp7044877pxb; Wed, 17 Feb 2021 23:02:44 -0800 (PST) X-Google-Smtp-Source: ABdhPJyEkS8fXvBcvupGUwLI5Z/jzpaC9I0PLmHUWX7ZVOsYAqQZFUw7eSLUyVLamdv+LPumxdg6 X-Received: by 2002:a17:906:b082:: with SMTP id x2mr2555448ejy.100.1613631763908; Wed, 17 Feb 2021 23:02:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613631763; cv=none; d=google.com; s=arc-20160816; b=VXoROBDgaiGhj+OGV0ZoODbQ+jl3hthBv1tt5Kwz81MMF002QRdYqpFGMFNFYCmZob tzeG0QFnp1reFPf0otgETcuuzawhN9v79nPAg1G+kePxMZV7/dGThCPtVJYgygwfpvqm ItsifXvEQppptV66krdLgedjfQOzRbzSqAr/GQo2rOqRwqoIb6TkzvnOqTl9Rq8F4ipG 5jQxOu35JqDsBkiH/2tvgTK0/rcBy5Z6s82zGezwXnLr/79a29AZ9pQhhPe75fACwWag /72PM8FVDdqIQYkKLzBknVp8VM3J5LtV4e7uQICb1P9PPDThtBup2F4eiNGssBlApxPo 3gZw== 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=coiC7DZFnkZ3fn3Had2P/TEGLEiePcjS1aihuXLrqo0=; b=ubBfiiUgFJ0OSbZ305ygO1j12KWtINk8dmOTgqU6+Q3pw0BacOgPQqAEjqwlHORPtg t1zgqTEHoF4nVpBSyqER6xyZ3jA7pu/8ZZPrgE4Rj4LB1KqAXNsN2DeP4k6qVv8OSVsS rp/yUH5wANo+7qkthaxKDfsGmMbqMGHq+2k2OD+CYo6EOCf+YNeCBg9yzF02d8tPU49r 8PFuJcoxyWWImoWF/6djgOreooiuAU4lN1272vVo7gJ4zQz3zsn+TulNUE2jt8zVA3xB EHgDw6wqhsrLE/oAE0yW3+BNuSZzqKkmzXg3jLdYUlKTyjNstp+iwSb2nvRzU8s72G8k ga6g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ZP4+TEG3; 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 bm18si2891033edb.545.2021.02.17.23.02.10; Wed, 17 Feb 2021 23:02:43 -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=ZP4+TEG3; 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 S229784AbhBRG7l (ORCPT + 99 others); Thu, 18 Feb 2021 01:59:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60454 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231243AbhBRGss (ORCPT ); Thu, 18 Feb 2021 01:48:48 -0500 Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 18D80C061756; Wed, 17 Feb 2021 22:47:55 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id f20so937091ioo.10; Wed, 17 Feb 2021 22:47:55 -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=coiC7DZFnkZ3fn3Had2P/TEGLEiePcjS1aihuXLrqo0=; b=ZP4+TEG3PRI4KEmWy+2KnTG2H1BvtyGd+Ke5l26XaLjHKlxY45DH/t8UDVqQfJqKR9 C+5AbhTx6txfQml9o9H6+0wPd1CtzXVrFiy7Iir+JN8/nNut7q6XiE0T0bFQrwgeYzuV dYAQ21uwLbuEW8ThWGmbc7vPtLZJLXIipW3cbXOQgoKnwhCEG46VqaHI1kI8pWkc3oX3 kkXevkAisePyXhw/n4ekcR9HrHuXRZHGvGFrwGD5+UKu+DvYky+5plGM7M+o7C/t2NDM EW2Pk3++F4zU8Wkcep/sjSKT5LUosprer1AmYvhU1Aei8XZmepcRftVQkyHwFqWdhgtc JNcQ== 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=coiC7DZFnkZ3fn3Had2P/TEGLEiePcjS1aihuXLrqo0=; b=Eevh9XFBS+rChSfLitWnpbkDINbyNsHivKgB3yEecAurgOchAzmOfLgDzVzdugiHvh hxpThYH73sugxQ0t1JotqgCcYu66VgDS0sKlh9VxNkJRYNlaQIQKkFrYqoiF+eLQ4eNA Cbehg3qLE0k2V7lK4y3180kvOeA1tKKt8FbC9/EqmcedtIYJnOO2uFCucj0a2Ye+4Mc+ dQzYd5PRqUck9Sdlpx7X+pc0xs0lPhbgnibFwcZ3baM5MmiLofDXu0Wc2u6TrWnlctOb 7bPD+g6kzoWvrKhJQcYUfyIIK1fqDEk3YA5wcg1mKUG7SPtYd1evgnMv65U2EWf4/vBy 4sEw== X-Gm-Message-State: AOAM531nJi+ezDRS8qDfqNO9NpxHmPcV6VKw4hYTe2xBJFfSW9L7tR/e upQbg/QirBsVi9k3ZBQsWOqT2/vPK7Z6zWFWxOM= X-Received: by 2002:a5d:9f4a:: with SMTP id u10mr2457301iot.186.1613630874598; Wed, 17 Feb 2021 22:47:54 -0800 (PST) MIME-Version: 1.0 References: <20210217172654.22519-1-lhenriques@suse.de> In-Reply-To: From: Amir Goldstein Date: Thu, 18 Feb 2021 08:47:43 +0200 Message-ID: Subject: Re: [PATCH v3] vfs: fix copy_file_range regression in cross-fs copies To: Olga Kornievskaia Cc: Luis Henriques , 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Thu, Feb 18, 2021 at 7:33 AM Olga Kornievskaia wrote: > > On Wed, Feb 17, 2021 at 3:30 PM Luis Henriques wrote: > > > > A regression has been reported by Nicolas Boichat, found while using the > > copy_file_range syscall to copy a tracefs file. Before commit > > 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the > > kernel would return -EXDEV to userspace when trying to copy a file across > > different filesystems. After this commit, the syscall doesn't fail anymore > > and instead returns zero (zero bytes copied), as this file's content is > > generated on-the-fly and thus reports a size of zero. > > > > This patch restores some cross-filesystems copy restrictions that existed > > prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across > > devices"). It also introduces a flag (COPY_FILE_SPLICE) that can be used > > by filesystems calling directly into the vfs copy_file_range to override > > these restrictions. Right now, only NFS needs to set this flag. > > > > Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") > > Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/ > > Link: https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx+BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/ > > Link: https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/ > > Reported-by: Nicolas Boichat > > Signed-off-by: Luis Henriques > > --- > > Ok, I've tried to address all the issues and comments. Hopefully this v3 > > is a bit closer to the final fix. > > > > Changes since v2 > > - do all the required checks earlier, in generic_copy_file_checks(), > > adding new checks for ->remap_file_range > > - new COPY_FILE_SPLICE flag > > - don't remove filesystem's fallback to generic_copy_file_range() > > - updated commit changelog (and subject) > > Changes since v1 (after Amir review) > > - restored do_copy_file_range() helper > > - return -EOPNOTSUPP if fs doesn't implement CFR > > - updated commit description > > In my testing, this patch breaks NFS server-to-server copy file. Hi Olga, Can you please provide more details on the failed tests. Does it fail on the client between two nfs mounts or does it fail on the server? If the latter, between which two filesystems on the server? Thanks, Amir.