linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the vfs-brauner tree with the bcachefs tree
@ 2024-06-17 16:55 Mark Brown
  0 siblings, 0 replies; 10+ messages in thread
From: Mark Brown @ 2024-06-17 16:55 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Kent Overstreet, Linux Kernel Mailing List,
	Linux Next Mailing List, Mateusz Guzik

[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]

Hi all,

Today's linux-next merge of the vfs-brauner tree got a conflict in:

  fs/bcachefs/fs.c

between commit:

  7124a8982b621 ("bcachefs: Add missing bch_inode_info.ei_flags init")

from the bcachefs tree and commit:

  9e89318f7b885 ("bcachefs: remove now spurious i_state initialization")

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.

diff --cc fs/bcachefs/fs.c
index 4a3e9f429cf7f,55348c5e04c52..0000000000000
--- a/fs/bcachefs/fs.c
+++ b/fs/bcachefs/fs.c
@@@ -227,10 -227,7 +227,9 @@@ static struct bch_inode_info *__bch2_ne
  	mutex_init(&inode->ei_update_lock);
  	two_state_lock_init(&inode->ei_pagecache_lock);
  	INIT_LIST_HEAD(&inode->ei_vfs_inode_list);
 +	inode->ei_flags = 0;
  	mutex_init(&inode->ei_quota_lock);
 +	memset(&inode->ei_devs_need_flush, 0, sizeof(inode->ei_devs_need_flush));
- 	inode->v.i_state = 0;
  
  	if (unlikely(inode_init_always(c->vfs_sb, &inode->v))) {
  		kmem_cache_free(bch2_inode_cache, inode);
diff --cc fs/nfs/symlink.c
index 13818129d268f,1c62a5a9f51d4..0000000000000
--- a/fs/nfs/symlink.c
+++ b/fs/nfs/symlink.c

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: linux-next: manual merge of the vfs-brauner tree with the bcachefs tree
  2024-02-26  0:12 Stephen Rothwell
@ 2024-03-12  3:56 ` Stephen Rothwell
  0 siblings, 0 replies; 10+ messages in thread
From: Stephen Rothwell @ 2024-03-12  3:56 UTC (permalink / raw)
  To: Christian Brauner, Kent Overstreet
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 1602 bytes --]

Hi all,

On Mon, 26 Feb 2024 11:12:57 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the vfs-brauner tree got a conflict in:
> 
>   fs/bcachefs/super-io.c
> 
> between commit:
> 
>   2881c58d14b6 ("bcachefs: bch2_print_opts()")
> 
> from the bcachefs tree and commit:
> 
>   9f2f767f5ef8 ("bcachefs: port block device access to file")
> 
> 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
> 
> diff --cc fs/bcachefs/super-io.c
> index 38a5073202c5,bd64eb68e84a..000000000000
> --- a/fs/bcachefs/super-io.c
> +++ b/fs/bcachefs/super-io.c
> @@@ -715,12 -715,11 +715,12 @@@ retry
>   			opt_set(*opts, nochanges, true);
>   	}
>   
> - 	if (IS_ERR(sb->bdev_handle)) {
> - 		ret = PTR_ERR(sb->bdev_handle);
> + 	if (IS_ERR(sb->s_bdev_file)) {
> + 		ret = PTR_ERR(sb->s_bdev_file);
>  +		prt_printf(&err, "error opening %s: %s", path, bch2_err_str(ret));
>   		goto err;
>   	}
> - 	sb->bdev = sb->bdev_handle->bdev;
> + 	sb->bdev = file_bdev(sb->s_bdev_file);
>   
>   	ret = bch2_sb_realloc(sb, 0);
>   	if (ret) {

This is now a conflict between the bcachefs tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* linux-next: manual merge of the vfs-brauner tree with the bcachefs tree
@ 2024-02-26  0:12 Stephen Rothwell
  2024-03-12  3:56 ` Stephen Rothwell
  0 siblings, 1 reply; 10+ messages in thread
From: Stephen Rothwell @ 2024-02-26  0:12 UTC (permalink / raw)
  To: Christian Brauner, Kent Overstreet
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]

Hi all,

Today's linux-next merge of the vfs-brauner tree got a conflict in:

  fs/bcachefs/super-io.c

between commit:

  2881c58d14b6 ("bcachefs: bch2_print_opts()")

from the bcachefs tree and commit:

  9f2f767f5ef8 ("bcachefs: port block device access to file")

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

diff --cc fs/bcachefs/super-io.c
index 38a5073202c5,bd64eb68e84a..000000000000
--- a/fs/bcachefs/super-io.c
+++ b/fs/bcachefs/super-io.c
@@@ -715,12 -715,11 +715,12 @@@ retry
  			opt_set(*opts, nochanges, true);
  	}
  
- 	if (IS_ERR(sb->bdev_handle)) {
- 		ret = PTR_ERR(sb->bdev_handle);
+ 	if (IS_ERR(sb->s_bdev_file)) {
+ 		ret = PTR_ERR(sb->s_bdev_file);
 +		prt_printf(&err, "error opening %s: %s", path, bch2_err_str(ret));
  		goto err;
  	}
- 	sb->bdev = sb->bdev_handle->bdev;
+ 	sb->bdev = file_bdev(sb->s_bdev_file);
  
  	ret = bch2_sb_realloc(sb, 0);
  	if (ret) {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* linux-next: manual merge of the vfs-brauner tree with the bcachefs tree
@ 2024-02-14 23:05 Stephen Rothwell
  0 siblings, 0 replies; 10+ messages in thread
From: Stephen Rothwell @ 2024-02-14 23:05 UTC (permalink / raw)
  To: Christian Brauner, Kent Overstreet
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Su Yue

[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]

Hi all,

Today's linux-next merge of the vfs-brauner tree got a conflict in:

  fs/bcachefs/super-io.c

between commits:

  7dcfb87af973 ("bcachefs: fix kmemleak in __bch2_read_super error handling path")
  4a3cf4df64fd ("bcachefs: bch2_print_opts()")

from the bcachefs tree and commit:

  1df39a40e912 ("bcachefs: port block device access to file")

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

diff --cc fs/bcachefs/super-io.c
index a3a9e85ab03c,ce8cf2d91f84..000000000000
--- a/fs/bcachefs/super-io.c
+++ b/fs/bcachefs/super-io.c
@@@ -715,12 -715,11 +715,12 @@@ retry
  			opt_set(*opts, nochanges, true);
  	}
  
- 	if (IS_ERR(sb->bdev_handle)) {
- 		ret = PTR_ERR(sb->bdev_handle);
+ 	if (IS_ERR(sb->s_bdev_file)) {
+ 		ret = PTR_ERR(sb->s_bdev_file);
 -		goto out;
 +		prt_printf(&err, "error opening %s: %s", path, bch2_err_str(ret));
 +		goto err;
  	}
- 	sb->bdev = sb->bdev_handle->bdev;
+ 	sb->bdev = file_bdev(sb->s_bdev_file);
  
  	ret = bch2_sb_realloc(sb, 0);
  	if (ret) {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* linux-next: manual merge of the vfs-brauner tree with the bcachefs tree
@ 2024-02-12 23:04 Stephen Rothwell
  0 siblings, 0 replies; 10+ messages in thread
From: Stephen Rothwell @ 2024-02-12 23:04 UTC (permalink / raw)
  To: Christian Brauner, Kent Overstreet
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Su Yue

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]

Hi all,

Today's linux-next merge of the vfs-brauner tree got a conflict in:

  fs/bcachefs/super-io.c

between commit:

  7dcfb87af973 ("bcachefs: fix kmemleak in __bch2_read_super error handling path")

from the bcachefs tree and commit:

  1df39a40e912 ("bcachefs: port block device access to file")

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

diff --cc fs/bcachefs/super-io.c
index 36988add581f,ce8cf2d91f84..000000000000
--- a/fs/bcachefs/super-io.c
+++ b/fs/bcachefs/super-io.c
@@@ -715,11 -715,11 +715,11 @@@ retry
  			opt_set(*opts, nochanges, true);
  	}
  
- 	if (IS_ERR(sb->bdev_handle)) {
- 		ret = PTR_ERR(sb->bdev_handle);
+ 	if (IS_ERR(sb->s_bdev_file)) {
+ 		ret = PTR_ERR(sb->s_bdev_file);
 -		goto out;
 +		goto err;
  	}
- 	sb->bdev = sb->bdev_handle->bdev;
+ 	sb->bdev = file_bdev(sb->s_bdev_file);
  
  	ret = bch2_sb_realloc(sb, 0);
  	if (ret) {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: linux-next: manual merge of the vfs-brauner tree with the bcachefs tree
  2023-10-26 19:34     ` Amir Goldstein
@ 2023-10-26 20:37       ` Kent Overstreet
  0 siblings, 0 replies; 10+ messages in thread
From: Kent Overstreet @ 2023-10-26 20:37 UTC (permalink / raw)
  To: Amir Goldstein
  Cc: Stephen Rothwell, Christian Brauner, Kent Overstreet,
	Linux Kernel Mailing List, Linux Next Mailing List, Jeff Layton,
	Chuck Lever

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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: linux-next: manual merge of the vfs-brauner tree with the bcachefs tree
  2023-10-26 18:35   ` Kent Overstreet
@ 2023-10-26 19:34     ` Amir Goldstein
  2023-10-26 20:37       ` Kent Overstreet
  0 siblings, 1 reply; 10+ messages in thread
From: Amir Goldstein @ 2023-10-26 19:34 UTC (permalink / raw)
  To: Kent Overstreet
  Cc: Stephen Rothwell, Christian Brauner, Kent Overstreet,
	Linux Kernel Mailing List, Linux Next Mailing List, Jeff Layton,
	Chuck Lever

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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: linux-next: manual merge of the vfs-brauner tree with the bcachefs tree
  2023-10-26  5:16 ` Amir Goldstein
@ 2023-10-26 18:35   ` Kent Overstreet
  2023-10-26 19:34     ` Amir Goldstein
  0 siblings, 1 reply; 10+ messages in thread
From: Kent Overstreet @ 2023-10-26 18:35 UTC (permalink / raw)
  To: Amir Goldstein
  Cc: Stephen Rothwell, Christian Brauner, Kent Overstreet,
	Linux Kernel Mailing List, Linux Next Mailing List, Jeff Layton,
	Chuck Lever

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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: linux-next: manual merge of the vfs-brauner tree with the bcachefs tree
  2023-10-25 23:01 Stephen Rothwell
@ 2023-10-26  5:16 ` Amir Goldstein
  2023-10-26 18:35   ` Kent Overstreet
  0 siblings, 1 reply; 10+ messages in thread
From: Amir Goldstein @ 2023-10-26  5:16 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Christian Brauner, Kent Overstreet, Kent Overstreet,
	Linux Kernel Mailing List, Linux Next Mailing List, Jeff Layton,
	Chuck Lever

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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* linux-next: manual merge of the vfs-brauner tree with the bcachefs tree
@ 2023-10-25 23:01 Stephen Rothwell
  2023-10-26  5:16 ` Amir Goldstein
  0 siblings, 1 reply; 10+ messages in thread
From: Stephen Rothwell @ 2023-10-25 23:01 UTC (permalink / raw)
  To: Christian Brauner, Kent Overstreet
  Cc: Amir Goldstein, Kent Overstreet, Linux Kernel Mailing List,
	Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]

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

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,
+ 
  	/*
  	 * 128 bit child FID (struct lu_fid)
  	 * 128 bit parent FID (struct lu_fid)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2024-06-17 16:55 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-06-17 16:55 linux-next: manual merge of the vfs-brauner tree with the bcachefs tree Mark Brown
  -- strict thread matches above, loose matches on Subject: below --
2024-02-26  0:12 Stephen Rothwell
2024-03-12  3:56 ` Stephen Rothwell
2024-02-14 23:05 Stephen Rothwell
2024-02-12 23:04 Stephen Rothwell
2023-10-25 23:01 Stephen Rothwell
2023-10-26  5:16 ` Amir Goldstein
2023-10-26 18:35   ` Kent Overstreet
2023-10-26 19:34     ` Amir Goldstein
2023-10-26 20:37       ` Kent Overstreet

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).