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

[Kefeng Wang]

On 9/26/2026 5:14 AM, Andrew Morton wrote:
> 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.


The mm series patches were based on Andrew's mm tree. However, sashiko
discovered a previously existing issue and sent a separate bugfix (based
on linux-xfs). But because both patches modified the same function,
xfs_btree_split_worker, it caused a context conflict.


* 26f42375404e xfs: fix NOFS state corruption in btree split worker
* 213bf447fc22 xfs: remove dead kswapd flag inheritance from btree split 
worker

I checked the latest linux-next, next-20260925, and found that the
current branch has issues while resolving the conflict, resulting in the
bugfix part being lost.

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

Maybe Mark will fix it in linux-next, or as Andrew said, merge all
the patches into the mm branch, but depends on the maintainer :)