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.
--
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;
On Fri, May 29, 2020 at 11:45:01AM +1000, Stephen Rothwell wrote:
> 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.
>
> --
> 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;
FWIW, I would be glad to have that old erofs commit moved over to
erofs tree... Folks?
Hi Al,
On Fri, May 29, 2020 at 02:51:11AM +0100, Al Viro wrote:
> On Fri, May 29, 2020 at 11:45:01AM +1000, Stephen Rothwell wrote:
> > 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.
> >
> > --
> > 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;
>
> 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
On Fri, May 29, 2020 at 11:40:07AM +0800, Gao Xiang wrote:
> 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.
On Fri, May 29, 2020 at 03:36:13PM +0100, Al Viro wrote:
> On Fri, May 29, 2020 at 11:40:07AM +0800, Gao Xiang wrote:
>
> > 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...
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...
>
> 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
>