Skip to contentSkip to conversation

linux-next: manual merge of the vfs tree with the erofs tree

DISCUSSION Stephen Rothwell 3 participants 5 messages May 29, 2020 Linux-next tree

lore
Share & tools
lore
#0 lore raw

Hi all,

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

fs/erofs/super.c

between commit:

e7cda1ee94f4 ("erofs: code cleanup by removing ifdef macro surrounding")

from the erofs tree and commit:

91a7c5e1d30e ("erofs: convert to use the new mount fs_context api")

from the vfs 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.

Signature · 28 lines
Cheers,
Stephen Rothwell

diff --cc fs/erofs/super.c
index 8e46d204a0c2,2c0bad903fa6..000000000000
--- a/fs/erofs/super.c
+++ b/fs/erofs/super.c
@@@ -408,16 -365,12 +365,9 @@@ static int erofs_fc_fill_super(struct s
  	sb->s_time_gran = 1;
  
  	sb->s_op = &erofs_sops;
 -
 -#ifdef CONFIG_EROFS_FS_XATTR
  	sb->s_xattr = erofs_xattr_handlers;
 -#endif
  
- 	/* set erofs default mount options */
- 	erofs_default_options(sbi);
- 
- 	err = erofs_parse_options(sb, data);
- 	if (err)
- 		return err;
- 
- 	if (test_opt(sbi, POSIX_ACL))
+ 	if (test_opt(ctx, POSIX_ACL))
  		sb->s_flags |= SB_POSIXACL;
  	else
  		sb->s_flags &= ~SB_POSIXACL;
#1 lore raw
Quoted 42 lines · Stephen Rothwell

Hi all,

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

fs/erofs/super.c

between commit:

e7cda1ee94f4 ("erofs: code cleanup by removing ifdef macro surrounding")

from the erofs tree and commit:

91a7c5e1d30e ("erofs: convert to use the new mount fs_context api")

from the vfs 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.

Signature · 2 lines
Cheers,
Stephen Rothwell
fs/erofs/super.c +0 -2
diff --cc fs/erofs/super.c
index 8e46d204a0c2,2c0bad903fa6..000000000000
@@@ -408,16 -365,12 +365,9 @@@ static int erofs_fc_fill_super(struct s
  	sb->s_time_gran = 1;
 
  	sb->s_op = &erofs_sops;
 -
 -#ifdef CONFIG_EROFS_FS_XATTR
  	sb->s_xattr = erofs_xattr_handlers;
 -#endif
 
- 	/* set erofs default mount options */
- 	erofs_default_options(sbi);

fs/erofs/super.c

Quoted 10 lines
fs/erofs/super.c +1 -6
- 
- 	err = erofs_parse_options(sb, data);
- 	if (err)
- 		return err;
- 
- 	if (test_opt(sbi, POSIX_ACL))
+ 	if (test_opt(ctx, POSIX_ACL))
  		sb->s_flags |= SB_POSIXACL;
  	else
  		sb->s_flags &= ~SB_POSIXACL;

FWIW, I would be glad to have that old erofs commit moved over to erofs tree... Folks?

#2 lore raw

Hi Al,

Quoted 41 lines · Al Viro
Quoted 40 lines · Stephen Rothwell

Hi all,

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

fs/erofs/super.c

between commit:

e7cda1ee94f4 ("erofs: code cleanup by removing ifdef macro surrounding")

from the erofs tree and commit:

91a7c5e1d30e ("erofs: convert to use the new mount fs_context api")

from the vfs 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.

Signature · 2 lines
Cheers,
Stephen Rothwell
fs/erofs/super.c +0 -0
diff --cc fs/erofs/super.c
index 8e46d204a0c2,2c0bad903fa6..000000000000
@@@ -408,16 -365,12 +365,9 @@@ static int erofs_fc_fill_super(struct s
  	sb->s_time_gran = 1;
 
  	sb->s_op = &erofs_sops;
 -
 -#ifdef CONFIG_EROFS_FS_XATTR
  	sb->s_xattr = erofs_xattr_handlers;
 -#endif
Quoted 15 lines

fs/erofs/super.c

Quoted 12 lines
fs/erofs/super.c +1 -8
- 	/* set erofs default mount options */
- 	erofs_default_options(sbi);
- 
- 	err = erofs_parse_options(sb, data);
- 	if (err)
- 		return err;
- 
- 	if (test_opt(sbi, POSIX_ACL))
+ 	if (test_opt(ctx, POSIX_ACL))
  		sb->s_flags |= SB_POSIXACL;
  	else
  		sb->s_flags &= ~SB_POSIXACL;

FWIW, I would be glad to have that old erofs commit moved over to erofs tree... Folks?

I'm fine with that, although I think it's mainly with vfs changes so could be better though with vfs tree. I will add this patch tomorrow anyway... Thanks for reminder!

Thanks,
Gao Xiang

#3 lore raw
Quoted 3 lines · Gao Xiang

I'm fine with that, although I think it's mainly with vfs changes so could be better though with vfs tree. I will add this patch tomorrow anyway... Thanks for reminder!

FWIW, my reasoning here is
* erofs tree exists and
* the patch is erofs-specific, affects nothing outside and
has no dependencies with anything currently done in VFS or in other filesystems and
* it does have (trivial) conflicts with the stuff in
erofs tree

So putting it into erofs tree would seem to be an obvious approach - minimizes the amount of cross-tree dependencies and headache for everyone involved...

I'm dropping it from #work.misc and #for-next now.

#4 lore raw
Quoted 14 lines · Al Viro
Quoted 3 lines · Gao Xiang

I'm fine with that, although I think it's mainly with vfs changes so could be better though with vfs tree. I will add this patch tomorrow anyway... Thanks for reminder!

FWIW, my reasoning here is
* erofs tree exists and
* the patch is erofs-specific, affects nothing outside and
has no dependencies with anything currently done in VFS or in other filesystems and
* it does have (trivial) conflicts with the stuff in
erofs tree

Quoted 3 lines

So putting it into erofs tree would seem to be an obvious approach - minimizes the amount of cross-tree dependencies and headache for everyone involved...

That is reasonable. btw, our initial thought was that relates to new mount apis and we weren't very confident if it really went the filesystem itself...

Quoted 2 lines

I'm dropping it from #work.misc and #for-next now.

I will push out for next cycle. Thanks for detailed explanation.

Thanks,
Gao Xiang

Quoted 1 line