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

[Kefeng Wang <wangkefeng.wang@huawei.com>]

On 9/26/2026 5:14 AM, Andrew Morton wrote:
> On Fri, 25 Sep 2026 17:03:58 +0200 Carlos Maiolino <cem@kernel.org> 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 :)