Message ID | 20231026100157.735d7dee@canb.auug.org.au |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:d641:0:b0:403:3b70:6f57 with SMTP id cy1csp292011vqb; Wed, 25 Oct 2023 16:02:24 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHLaRQyAOwxKNl5UOcSPuGCRxG1nGi8DHZ/2yIAcwr902wRdy0Cg5++57yIeFzqF9EzpEvf X-Received: by 2002:a05:6122:4e08:b0:49d:2a13:58fc with SMTP id ge8-20020a0561224e0800b0049d2a1358fcmr774089vkb.2.1698274944327; Wed, 25 Oct 2023 16:02:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698274944; cv=none; d=google.com; s=arc-20160816; b=SrkClE1laM+xG2rN+B4zapMcLZXfrPUJ07CMUALz9+DcEc/AttomI11V1R7oCSRfq7 oLJWoj1QN1T/11Bdep+Yk5f5MzkS1BGcGPkCkXtnnknE0oVCuXn4A+3/EEpiQy7ncgjP Rbi7MPnbWBNswGNdHQlmQetWVUC8C63V4NgvHU8WFX4NjqllZz1ZFEbt+gjsvmrSFGWe EuYtJrAp+uton8Eil2aafEfV3FlLiDL/qbXSf6RzBe0pm3PDfrFoq9T0GuAxlRgL20yy yk0RTM99EmZnOQxf2GCAXfxthWN8bH8MJQAE8QX07+QnJ00FGqm7LiTJEvIfLnAtOFe/ 5u+w== 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:subject:cc:to:from:date :dkim-signature; bh=ILvvl/AKCad66JyAk+uyU1wjPs+a55UCOHy+Tqem/EA=; fh=BXs9BzR+7Mz2O35M8Usg+z5YjW0p7+SB87vx6IqJEnQ=; b=yxZ2YhvVBDkb1Vdb4TxjIOJi4CImwxccAsHJgIRsV0DDC1MoJ6dGGXPRjEtftT0cwn ug9q3lwdKmGSpB6doLfUTDb7XEWR5OQMJmy1bs6CLahLpKIz/AQGqPlvf83MO2w5Zixf PvtlGCegJ1tc2kQXsXnUTUXXXSusd8Hxat0x7XzlZ3C9sUCWNyV/n5QiRfKGxXbod6yK kySp/NivkKkit1EvBBFKQa6WiZoUqjfSsZoRHMq+NvN1CNUKu6+5N0TxEEN/Zji7gjES NNa2w6cNTQ8BURO+6HaoWr8Rz5mInUVe0ggoV7NHJZ29P1Hh9cFCjpQ1xtVvC43sPO0U glBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@canb.auug.org.au header.s=201702 header.b="Y/L8SHrZ"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=canb.auug.org.au Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id n3-20020a1fd603000000b0048fdca6224fsi189441vkg.41.2023.10.25.16.02.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Oct 2023 16:02:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; dkim=pass header.i=@canb.auug.org.au header.s=201702 header.b="Y/L8SHrZ"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=canb.auug.org.au Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 38EE2802ACCE; Wed, 25 Oct 2023 16:02:21 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229910AbjJYXCI (ORCPT <rfc822;a1648639935@gmail.com> + 25 others); Wed, 25 Oct 2023 19:02:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51416 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229573AbjJYXCG (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 25 Oct 2023 19:02:06 -0400 Received: from gandalf.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 132C0115; Wed, 25 Oct 2023 16:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canb.auug.org.au; s=201702; t=1698274919; bh=ILvvl/AKCad66JyAk+uyU1wjPs+a55UCOHy+Tqem/EA=; h=Date:From:To:Cc:Subject:From; b=Y/L8SHrZpbwLuA4zfNVcKCmbVAhyvmSMQzMsoBT/cDTJTHsJq40ngSJ4JhFwwlQLb mL8cZkFe+RnanmCwEC8iOypT+V1jmWgbbNRDYk2Ds690IcKneQICkXbkL/BU/265gn 9dy6a+GEH3TDEbgANx5GUfndM6KAtMMTBh6XqQ20nXvEV+7YRhkj5FmZA426tLrSIs 6exE1zAT7Y2JDhAP3JPYpoNroQbYLtMwbiAP/wprvR0FD/lqeQAN6ZaNgAuiBaib3t GkgJz2KRJYkpqRrr/s28SP6dqGVAtnnj4Xb/6wMsJJhDvGMDFpsBvC0zHNbnggsuUn ffr1GW5LV1+hw== Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4SG4F24V4Vz4wx8; Thu, 26 Oct 2023 10:01:58 +1100 (AEDT) Date: Thu, 26 Oct 2023 10:01:57 +1100 From: Stephen Rothwell <sfr@canb.auug.org.au> To: Christian Brauner <brauner@kernel.org>, Kent Overstreet <kent.overstreet@linux.dev> Cc: Amir Goldstein <amir73il@gmail.com>, Kent Overstreet <kent.overstreet@gmail.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux Next Mailing List <linux-next@vger.kernel.org> Subject: linux-next: manual merge of the vfs-brauner tree with the bcachefs tree Message-ID: <20231026100157.735d7dee@canb.auug.org.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/VmBDWPP88GD83wpyU+t3/kY"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Wed, 25 Oct 2023 16:02:21 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780770348122217646 X-GMAIL-MSGID: 1780770348122217646 |
Series |
linux-next: manual merge of the vfs-brauner tree with the bcachefs tree
|
|
Commit Message
Stephen Rothwell
Oct. 25, 2023, 11:01 p.m. UTC
Hi all, Today's linux-next merge of the vfs-brauner tree got a conflict in: include/linux/exportfs.h between commit: 85e95ca7cc48 ("bcachefs: Update export_operations for snapshots") from the bcachefs tree and commit: 2560fa66d2ac ("exportfs: define FILEID_INO64_GEN* file handle types") from the vfs-brauner tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts.
Comments
On Thu, Oct 26, 2023 at 2:02 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > Today's linux-next merge of the vfs-brauner tree got a conflict in: > > include/linux/exportfs.h > > between commit: > > 85e95ca7cc48 ("bcachefs: Update export_operations for snapshots") > > from the bcachefs tree and commit: > > 2560fa66d2ac ("exportfs: define FILEID_INO64_GEN* file handle types") > > from the vfs-brauner tree. > > I fixed it up (see below) and can carry the fix as necessary. This > is now fixed as far as linux-next is concerned, but any non trivial > conflicts should be mentioned to your upstream maintainer when your tree > is submitted for merging. You may also want to consider cooperating > with the maintainer of the conflicting tree to minimise any particularly > complex conflicts. > > -- > Cheers, > Stephen Rothwell [adding exportfs maintainers] > > diff --cc include/linux/exportfs.h > index be9900cc8786,21bae8bfeef1..000000000000 > --- a/include/linux/exportfs.h > +++ b/include/linux/exportfs.h > @@@ -98,12 -98,17 +98,23 @@@ enum fid_type > */ > FILEID_FAT_WITH_PARENT = 0x72, > > + /* > + * 64 bit inode number, 32 bit subvolume, 32 bit generation number: > + */ > + FILEID_BCACHEFS_WITHOUT_PARENT = 0x80, > + FILEID_BCACHEFS_WITH_PARENT = 0x81, > + > + /* > + * 64 bit inode number, 32 bit generation number. > + */ > - FILEID_INO64_GEN = 0x81, > ++ FILEID_INO64_GEN = 0x82, > + > + /* > + * 64 bit inode number, 32 bit generation number, > + * 64 bit parent inode number, 32 bit parent generation. > + */ > - FILEID_INO64_GEN_PARENT = 0x82, > ++ FILEID_INO64_GEN_PARENT = 0x83, > + This is wrong. Those are filesystem defined constants. Please don't change them. 0x81/0x82 have been used by xfs and fuse for years, even though neither defined a constant in this enum so far. Conflicting with FILEID_BCACHEFS_WITH_PARENT is not a serious issue, but I encourage Kent to pick different constants for bcachefs or keep the bcachefs constants out of this enum. It is a slight inconvenience for users that have bcachefs exported to NFS clients and upgrade their server, but maybe that is acceptable. In overlayfs, we encoded type OVL_FILEID_V0 and switched to encoding type OVL_FILEID_V1, but we still accept decoding of both types, neither of which are listed in this enum BTW. Adding fid types to this enum is not required. This enum is a place to standardize and for different fs to share the same fid type/encoding as is the case with FILEID_INO{32,64}_GEN*. IMO, the bcachefs constant do not follow the convention in this enum and their format is unlikely to be used by other fs, so they should not be added to this enum at all. Thanks, Amir.
On Thu, Oct 26, 2023 at 08:16:14AM +0300, Amir Goldstein wrote: > On Thu, Oct 26, 2023 at 2:02 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > Hi all, > > > > Today's linux-next merge of the vfs-brauner tree got a conflict in: > > > > include/linux/exportfs.h > > > > between commit: > > > > 85e95ca7cc48 ("bcachefs: Update export_operations for snapshots") > > > > from the bcachefs tree and commit: > > > > 2560fa66d2ac ("exportfs: define FILEID_INO64_GEN* file handle types") > > > > from the vfs-brauner tree. > > > > I fixed it up (see below) and can carry the fix as necessary. This > > is now fixed as far as linux-next is concerned, but any non trivial > > conflicts should be mentioned to your upstream maintainer when your tree > > is submitted for merging. You may also want to consider cooperating > > with the maintainer of the conflicting tree to minimise any particularly > > complex conflicts. > > > > -- > > Cheers, > > Stephen Rothwell > > [adding exportfs maintainers] > > > > > diff --cc include/linux/exportfs.h > > index be9900cc8786,21bae8bfeef1..000000000000 > > --- a/include/linux/exportfs.h > > +++ b/include/linux/exportfs.h > > @@@ -98,12 -98,17 +98,23 @@@ enum fid_type > > */ > > FILEID_FAT_WITH_PARENT = 0x72, > > > > + /* > > + * 64 bit inode number, 32 bit subvolume, 32 bit generation number: > > + */ > > + FILEID_BCACHEFS_WITHOUT_PARENT = 0x80, > > + FILEID_BCACHEFS_WITH_PARENT = 0x81, > > + > > + /* > > + * 64 bit inode number, 32 bit generation number. > > + */ > > - FILEID_INO64_GEN = 0x81, > > ++ FILEID_INO64_GEN = 0x82, > > + > > + /* > > + * 64 bit inode number, 32 bit generation number, > > + * 64 bit parent inode number, 32 bit parent generation. > > + */ > > - FILEID_INO64_GEN_PARENT = 0x82, > > ++ FILEID_INO64_GEN_PARENT = 0x83, > > + > > This is wrong. > Those are filesystem defined constants. > Please don't change them. > > 0x81/0x82 have been used by xfs and fuse for years, > even though neither defined a constant in this enum so far. Perhaps we could get that fixed...? > Conflicting with FILEID_BCACHEFS_WITH_PARENT is not > a serious issue, but I encourage Kent to pick different constants > for bcachefs or keep the bcachefs constants out of this enum. Happy to do so. Since it seems this enum doesn't have all the constants I'd need to avoid conflicting with, I might need some help here :) > It is a slight inconvenience for users that have bcachefs exported > to NFS clients and upgrade their server, but maybe that is acceptable. > In overlayfs, we encoded type OVL_FILEID_V0 and switched to encoding > type OVL_FILEID_V1, but we still accept decoding of both types, neither > of which are listed in this enum BTW. > > Adding fid types to this enum is not required. > This enum is a place to standardize and for different fs to share the same > fid type/encoding as is the case with FILEID_INO{32,64}_GEN*. > IMO, the bcachefs constant do not follow the convention in this > enum and their format is unlikely to be used by other fs, so > they should not be added to this enum at all. Eh? Most of the constants here appear to be completely filesystem specific - I see UDF, nilfs, btrfs, fat... And since you also don't want conflicts with fid_types that aren't defined here, it seems like they really should all be here.
On Thu, Oct 26, 2023 at 9:35 PM Kent Overstreet <kent.overstreet@linux.dev> wrote: > > On Thu, Oct 26, 2023 at 08:16:14AM +0300, Amir Goldstein wrote: > > On Thu, Oct 26, 2023 at 2:02 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > > > Hi all, > > > > > > Today's linux-next merge of the vfs-brauner tree got a conflict in: > > > > > > include/linux/exportfs.h > > > > > > between commit: > > > > > > 85e95ca7cc48 ("bcachefs: Update export_operations for snapshots") > > > > > > from the bcachefs tree and commit: > > > > > > 2560fa66d2ac ("exportfs: define FILEID_INO64_GEN* file handle types") > > > > > > from the vfs-brauner tree. > > > > > > I fixed it up (see below) and can carry the fix as necessary. This > > > is now fixed as far as linux-next is concerned, but any non trivial > > > conflicts should be mentioned to your upstream maintainer when your tree > > > is submitted for merging. You may also want to consider cooperating > > > with the maintainer of the conflicting tree to minimise any particularly > > > complex conflicts. > > > > > > -- > > > Cheers, > > > Stephen Rothwell > > > > [adding exportfs maintainers] > > > > > > > > diff --cc include/linux/exportfs.h > > > index be9900cc8786,21bae8bfeef1..000000000000 > > > --- a/include/linux/exportfs.h > > > +++ b/include/linux/exportfs.h > > > @@@ -98,12 -98,17 +98,23 @@@ enum fid_type > > > */ > > > FILEID_FAT_WITH_PARENT = 0x72, > > > > > > + /* > > > + * 64 bit inode number, 32 bit subvolume, 32 bit generation number: > > > + */ > > > + FILEID_BCACHEFS_WITHOUT_PARENT = 0x80, > > > + FILEID_BCACHEFS_WITH_PARENT = 0x81, > > > + > > > + /* > > > + * 64 bit inode number, 32 bit generation number. > > > + */ > > > - FILEID_INO64_GEN = 0x81, > > > ++ FILEID_INO64_GEN = 0x82, > > > + > > > + /* > > > + * 64 bit inode number, 32 bit generation number, > > > + * 64 bit parent inode number, 32 bit parent generation. > > > + */ > > > - FILEID_INO64_GEN_PARENT = 0x82, > > > ++ FILEID_INO64_GEN_PARENT = 0x83, > > > + > > > > This is wrong. > > Those are filesystem defined constants. > > Please don't change them. > > > > 0x81/0x82 have been used by xfs and fuse for years, > > even though neither defined a constant in this enum so far. > > Perhaps we could get that fixed...? commit 2560fa66d2ac ("exportfs: define FILEID_INO64_GEN* file handle types") fixes that for fuse. I may fix up xfs to use these constants later. > > > Conflicting with FILEID_BCACHEFS_WITH_PARENT is not > > a serious issue, but I encourage Kent to pick different constants > > for bcachefs or keep the bcachefs constants out of this enum. > > Happy to do so. Since it seems this enum doesn't have all the constants > I'd need to avoid conflicting with, I might need some help here :) > Technically, you don't *need* to avoid conflicting with fileid types of other filesystems and you do not *need* to define your constant in this enum. It serves no real purpose unless your constant declares a fileid format that other filesystems also use. See the comment at the top of the enum. > > It is a slight inconvenience for users that have bcachefs exported > > to NFS clients and upgrade their server, but maybe that is acceptable. > > In overlayfs, we encoded type OVL_FILEID_V0 and switched to encoding > > type OVL_FILEID_V1, but we still accept decoding of both types, neither > > of which are listed in this enum BTW. > > > > Adding fid types to this enum is not required. > > This enum is a place to standardize and for different fs to share the same > > fid type/encoding as is the case with FILEID_INO{32,64}_GEN*. > > IMO, the bcachefs constant do not follow the convention in this > > enum and their format is unlikely to be used by other fs, so > > they should not be added to this enum at all. > > Eh? > > Most of the constants here appear to be completely filesystem specific - > I see UDF, nilfs, btrfs, fat... > There is no good reason for those to be in the enum either other than documentation. > And since you also don't want conflicts with fid_types that aren't > defined here, it seems like they really should all be here. If you define your constants internally in bcachefs, I don't care about conflicts, but if I were you, I would avoid conflicts with the known types. If you want to define your constants in this enum please choose any vacant 0x?{1,2} values. 0xb{1,2}? Thanks, Amir.
On Thu, Oct 26, 2023 at 10:34:18PM +0300, Amir Goldstein wrote: > On Thu, Oct 26, 2023 at 9:35 PM Kent Overstreet > > > This is wrong. > > > Those are filesystem defined constants. > > > Please don't change them. > > > > > > 0x81/0x82 have been used by xfs and fuse for years, > > > even though neither defined a constant in this enum so far. > > > > Perhaps we could get that fixed...? > > commit 2560fa66d2ac ("exportfs: define FILEID_INO64_GEN* > file handle types") fixes that for fuse. > I may fix up xfs to use these constants later. Wonderful > > > Conflicting with FILEID_BCACHEFS_WITH_PARENT is not > > > a serious issue, but I encourage Kent to pick different constants > > > for bcachefs or keep the bcachefs constants out of this enum. > > > > Happy to do so. Since it seems this enum doesn't have all the constants > > I'd need to avoid conflicting with, I might need some help here :) > > > > Technically, you don't *need* to avoid conflicting with fileid types > of other filesystems and you do not *need* to define your constant > in this enum. It serves no real purpose unless your constant > declares a fileid format that other filesystems also use. > > See the comment at the top of the enum. > > > > It is a slight inconvenience for users that have bcachefs exported > > > to NFS clients and upgrade their server, but maybe that is acceptable. > > > In overlayfs, we encoded type OVL_FILEID_V0 and switched to encoding > > > type OVL_FILEID_V1, but we still accept decoding of both types, neither > > > of which are listed in this enum BTW. > > > > > > Adding fid types to this enum is not required. > > > This enum is a place to standardize and for different fs to share the same > > > fid type/encoding as is the case with FILEID_INO{32,64}_GEN*. > > > IMO, the bcachefs constant do not follow the convention in this > > > enum and their format is unlikely to be used by other fs, so > > > they should not be added to this enum at all. > > > > Eh? > > > > Most of the constants here appear to be completely filesystem specific - > > I see UDF, nilfs, btrfs, fat... > > > > There is no good reason for those to be in the enum either > other than documentation. Well, clearly not: since the cause of this whole thread was conflicts with constants that were /not/ previously in this enum. > > > And since you also don't want conflicts with fid_types that aren't > > defined here, it seems like they really should all be here. > > If you define your constants internally in bcachefs, I don't care > about conflicts, but if I were you, I would avoid conflicts with > the known types. > > If you want to define your constants in this enum please choose > any vacant 0x?{1,2} values. 0xb{1,2}? That'll do, I'll patch accordingly.
diff --cc include/linux/exportfs.h index be9900cc8786,21bae8bfeef1..000000000000 --- a/include/linux/exportfs.h