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=-7.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 375A1C433DB for ; Thu, 18 Feb 2021 06:59:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C232864E3E for ; Thu, 18 Feb 2021 06:59:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230133AbhBRG5M (ORCPT ); Thu, 18 Feb 2021 01:57:12 -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-Google-Smtp-Source: ABdhPJyXIPnk2aIwWEt6skFJ+WTgQlXts+vv2jLkbhIcChUBX+p0Yv1qMnm1M6CE0tczJ7I9La5fe6dLBQ2kNBQYlkU= 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: ceph-devel@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.