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

Hi all,

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

fs/xfs/libxfs/xfs_btree.c

between commit:

4d1d71f8b90dc ("xfs: remove dead kswapd flag inheritance from btree split worker")

from the mm tree and commit:

26f42375404e5 ("xfs: fix NOFS state corruption in btree split worker")

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

fs/xfs/libxfs/xfs_btree.c +0 -0

diff --combined fs/xfs/libxfs/xfs_btree.c
index 6738d9d1511bc,7effebe297ea0..0000000000000
@@@ -2994,6 -2994,7 +2994,6 @@@ struct xfs_btree_split_args 
  	struct xfs_btree_cur	**curp;
  	int			*stat;		/* success/failure */
  	int			result;
 -	bool			kswapd;	/* allocation in kswapd context */
  	struct completion	*done;
  	struct work_struct	work;
  };

@@@ -3007,18 -3008,39 +3007,18 @@@ xfs_btree_split_worker
  {
  	struct xfs_btree_split_args	*args = container_of(work,
  						struct xfs_btree_split_args, work);
 -	unsigned long		pflags;
 -	unsigned long		new_pflags = 0;
 -	unsigned int		nofs_flags;
 -
 -	/*
 -	 * we are in a transaction context here, but may also be doing work
 -	 * in kswapd context, and hence we may need to inherit that state
 -	 * temporarily to ensure that we don't block waiting for memory reclaim
 -	 * in any way.
 -	 */
 -	if (args->kswapd)
 -		new_pflags |= PF_MEMALLOC | PF_KSWAPD;
 -
 -	current_set_flags_nested(&pflags, new_pflags);
 -
 -	/*
 -	 * Don't use xfs_trans_set_context() here: it would overwrite the
 -	 * caller's saved NOFS state in tp->t_pflags. Use a local scope.
 -	 */
 -	nofs_flags = memalloc_nofs_save();
 +	xfs_trans_set_context(args->cur->bc_tp);
 
  	args->result = __xfs_btree_split(args->cur, args->level, args->ptrp,
  					 args->key, args->curp, args->stat);
 
 -	memalloc_nofs_restore(nofs_flags);
 -	current_restore_flags_nested(&pflags, new_pflags);
 +	xfs_trans_clear_context(args->cur->bc_tp);
 
  	/*
  	 * Do not access args after complete() has run here. We don't own args
  	 * and the owner may run and free args before we return here.
  	 */
  	complete(args->done);
 -
  }
 
  /*

@@@ -3062,7 -3084,7 +3062,7 @@@ xfs_btree_split
  	args.curp = curp;
  	args.stat = stat;
  	args.done = &done;
 -	args.kswapd = current_is_kswapd();
 +
  	INIT_WORK_ONSTACK(&args.work, xfs_btree_split_worker);
  	queue_work(xfs_alloc_wq, &args.work);
  	wait_for_completion(&done);

Quoted 6 lines · Mark Brown

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

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?

Quoted 10 lines · Carlos Maiolino

Quoted 6 lines · Mark Brown

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.

Quoted 4 lines

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.

Quoted 19 lines · Mark Brown

Quoted 10 lines · Carlos Maiolino

Quoted 6 lines · Mark Brown

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.

Quoted 4 lines

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?

Quoted 6 lines

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.

Quoted 27 lines · On Fri, 25 Sep 2026 17:03:58 +0200 Carlos Maiolino <[email protected]> wrote:

Quoted 19 lines · Mark Brown

Quoted 10 lines · Carlos Maiolino

Quoted 6 lines · Mark Brown

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.

Quoted 4 lines

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?

Quoted 6 lines

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.

Quoted 6 lines

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?

Quoted 2 lines · Andrew Morton

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 :)

There is a fixup in -next already which is hopefully OK, I don't recall it being especially bad so probably Linus would be OK with resolving it.

Quoted 2 lines · Mark Brown

There is a fixup in -next already which is hopefully OK, I don't recall it being especially bad so probably Linus would be OK with resolving it.

Hi Mark,

The fixup in -next takes the mm side of xfs_btree_split_worker() verbatim, which puts xfs_trans_set_context()/xfs_trans_clear_context() back and drops

23f91a51425e ("xfs: fix NOFS state corruption in btree split worker")

next-20261016 still has it this way.

The two changes are independent:

2e6a6ca06fec ("xfs: remove dead kswapd flag inheritance from btree split worker")

removes the pflags handling, and the xfs fix replaces the transaction context calls with a local memalloc_nofs_save()/memalloc_nofs_restore(). The resolution should keep both. The delta against next-20261016 is below.

Neither tree conflicts with v7.3 here on its own, so whichever of the mm and xfs pull requests goes second will hit this. Andrew, Carlos, could that pull request point Linus at this resolution rather than the one earlier in this thread?

This is the resolution llminus generates:

fs/xfs/libxfs/xfs_btree.c +8 -2

index 6738d9d1511bc..2434c54a35708 100644
@@ -3007,12 +3007,18 @@ xfs_btree_split_worker(
 {
 	struct xfs_btree_split_args	*args = container_of(work,
 						struct xfs_btree_split_args, work);
-	xfs_trans_set_context(args->cur->bc_tp);
+	unsigned int		nofs_flags;
+
+	/*
+	 * Don't use xfs_trans_set_context() here: it would overwrite the
+	 * caller's saved NOFS state in tp->t_pflags. Use a local scope.
+	 */
+	nofs_flags = memalloc_nofs_save();
 
 	args->result = __xfs_btree_split(args->cur, args->level, args->ptrp,
 					 args->key, args->curp, args->stat);
 
-	xfs_trans_clear_context(args->cur->bc_tp);
+	memalloc_nofs_restore(nofs_flags);
 
 	/*
 	 * Do not access args after complete() has run here. We don't own args

Signature · 3 lines

-- 
Thanks,
Sasha

Quoted 2 lines · Mark Brown

There is a fixup in -next already which is hopefully OK, I don't recall it being especially bad so probably Linus would be OK with resolving it.

Hi Mark,

The fixup in -next takes the mm side of xfs_btree_split_worker() verbatim, which puts xfs_trans_set_context()/xfs_trans_clear_context() back and drops