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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 295E5C433FE for ; Tue, 22 Mar 2022 18:24:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240391AbiCVSZc (ORCPT ); Tue, 22 Mar 2022 14:25:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39304 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240324AbiCVSZS (ORCPT ); Tue, 22 Mar 2022 14:25:18 -0400 Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 32649DE83 for ; Tue, 22 Mar 2022 11:23:34 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id w25so22704271edi.11 for ; Tue, 22 Mar 2022 11:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=85Ws1qb644UrDxX3GqtVYKt4YI7t6y+/3TtLCRrTTKc=; b=Ku1bCHHBy4U/B0ntBvZYaNo6sJY8WQONWU//cYuzD1bsiWewQg70QTeDzl2hXY4XFN NwP5Gw/RMT8B+yi8bWlXB4Skrv6zKuyqhznjY3mFaV89GZ3JlOBl5l20RiE80NBafVP2 AU1HrlWh98Cpn2TbAJ9BGX4m7EnwW3Eei6uQg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=85Ws1qb644UrDxX3GqtVYKt4YI7t6y+/3TtLCRrTTKc=; b=a44Sy1RgXPJfgT5jF7fmWHXcURSJYjg+NtNfzEMzORLvjzEH4gBAkbn57XXNTrFTkp X0wbMMZt8fIzOfTJswRuAzMQsUuw7j9EMW5XxvLF1LPc5vXhFEUxelYE0gJZk+XsIITF I63wppU2/nuPGsrDLgNm9gfuySst+/RC4Dn9NnA7g4ivcSBjViYgIDM+lU8BfB85HPfg T77zU/QHY45LuxqNzUcb32QcK5kbe97U6gKPmVYL/T9GjCWXhIZ7TzpAiv+oR5LBdtZE LWyR1gmmE91vSr2l2QXvk2JIl7bfGtd1hh74Yf/Q9ITUm6dC5Qq2TP6tcTi+bJw/G+Xe qUFA== X-Gm-Message-State: AOAM533yzyRFgk9jlGGY7A2P0X3RMkEpdmFOkSaRkkVWZc63duGo4brm B6cxQTN3FWgQ3he4FdNp/fEroe+rSS5cV2FhW3mXbg== X-Google-Smtp-Source: ABdhPJwMtH2ef4MJrXE0r5q0QsAUPWiDH4EPuum8RS4ja9iTxc2/V115+eJwjZT4xBGe3Onik6xG+a123W5HezabEwg= X-Received: by 2002:aa7:c755:0:b0:419:2f66:e22c with SMTP id c21-20020aa7c755000000b004192f66e22cmr14457833eds.381.1647973412741; Tue, 22 Mar 2022 11:23:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Tue, 22 Mar 2022 11:23:21 -0700 Message-ID: Subject: Re: [GIT PULL] Btrfs updates for 5.18 To: David Sterba , linux-fsdevel Cc: linux-btrfs , lkml Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 21, 2022 at 2:37 PM David Sterba wrote: > > - allow reflinks/deduplication from two different mounts of the same > filesystem So I've pulled this, and it looks ok, but I'm not getting the warm and fuzzies. In particular, I'm not seeing any commentary about different filesystems for this. There are several filesystems that use that ->remap_file_range() operation, so these relaxed rules don't just affect btrfs. Yes, yes, checking for i_sb matching does seem sensible, but I'd *really* have liked some sign that people checked with other filesystem maintainers and this is ok for all of them, and they didn't make assumptions about "always same mount" rather than "always same filesystem". This affects at least cifs, nfs, overlayfs and ocfs2. Adding fsdevel, and pointing to that - if (src_file->f_path.mnt != dst_file->f_path.mnt) + if (file_inode(src_file)->i_sb != file_inode(dst_file)->i_sb) change in commit 9f5710bbfd30 ("fs: allow cross-vfsmount reflink/dedupe") And yes, there was already a comment about "Practically, they only need to be on the same file system" from before that matches the new behavior, but hey, comments have been known to be wrong in the past too. And yes, I'm also aware that do_clone_file_range() already had that exact same i_sb check and it's not new, but since ioctl_file_clone() cheched for the mount path, I don't think you could actually reach it without being on the same mount. And while discussing these sanity checks: wouldn't it make sense to check that *both* the source file and the destination file support that remap_file_range() op, and it's the same op? Yes, yes, it probably always is in practice, but I could imagine some type confusion thing. So wouldn't it be nice to also have something like if (dst_file->f_op != src_file->f_op) goto out_drop_write; in there? I'm thinking "how about dedupe from a directory to a regular file" kind of craziness... Linus