Re: linux-next: manual merge of the fs-next tree with the mm tree

[Andrew Morton]

On Fri, 25 Sep 2026 17:03:58 +0200 Carlos Maiolino <cem@xxxxxxxxxx> wrote:

> On Fri, Sep 25, 2026 at 02:11:28PM +0100, Mark Brown wrote:
> > On Fri, Sep 25, 2026 at 02:26:25PM +0200, Carlos Maiolino wrote:
> > > On Thu, Sep 24, 2026 at 01:09:09PM +0100, Mark Brown wrote:
> > 
> > > > 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.
> > 
> > > Do you mean non-trivial conflicts with linux-next? I always attempt a
> > 
> > With other trees in linux-next.
> > 
> > > merge against Linus's tree before sending a pull-request to check and
> > > annotate any possible conflict, but I have never done that for
> > > linux-next. I can do that, no problems. Where should I send a
> > > notification to? linux-next@vger?
> > 
> > If there's anything interesting it can be helpful for me to get a heads
> > up on the resolution but the main thing (and half the point of having
> > -next) is to coordinate with other trees that you're colliding with.
> > You don't specifically need to check, I'll tell you if I notice
> > something, but OTOH if you know your work is going to be colliding with
> > someone else's it's good to coordinate.
> 
> Ok, that sounds fair Mark. I honestly didn't expect this patch to
> collide with Andrew's tree. The submitter sent both of them initially,
> Andrew picked one, and I asked the submitter to send the second one
> individually for me to pick up. But I didn't expect it to cause a
> collision. Next time it happens I'll try to keep an eye on the ending
> result.

I don't think much went wrong here.  Keeping the [1/4] xfs patch in
mm.git is appropriate, as it's part of a series.  Unfortunately Kefeng's
standalone "xfs: fix NOFS state corruption in btree split worker"
conflicted with it.

I suppose I could add the standalone fix to mm-git as well (with xfs
maintainer acks), just to make life easier for everyone?