Hi all,

Today's linux-next merge of the vfs-brauner tree got conflicts in:

  kernel/ptrace.c
  fs/exec.c
  include/linux/binfmts.h
  kernel/exec_state.c

between commits:

  6b1c66c9cca99 ("exec_state: relocate dumpable information")
  38205ecbe6b6d ("exec: free the old mm outside the exec locks")

from the nfsd tree and commits:

  6b1c66c9cca99 ("exec_state: relocate dumpable information")
  38205ecbe6b6d ("exec: free the old mm outside the exec locks")

from the vfs-brauner tree plus some other context from vfs-brauner
merges.  Specifically this is due to the nfsd tree having a build break
from the vfs-brauner tree it's based on and being held at an old version
with it's old version of vfs-brauner while the vfs-brauner tree has been
updated.  However since the build issue isn't fixed in the version of
vfs-brauner I have today (I saw a patch on the list though, I guess this
will be fixed tomorrow?) the below merge isn't actually going to be in
-next, I'm merging the old version that's shared with nfsd and there's
no actual conflict in today's tree.

Are you sure it's a good idea to base the nfsd tree on something
that's rebasing?

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.

diff --combined fs/exec.c
index 894added369dd,b92fe7db176cf..0000000000000
--- a/fs/exec.c
+++ b/fs/exec.c
@@@ -836,16 -836,18 +836,18 @@@ EXPORT_SYMBOL(read_code)
  /*
   * Maps the mm_struct mm into the current task struct.
   * On success, this function returns with exec_update_lock
-  * held for writing.
+  * held for writing. The replaced address space is stashed in
+  * bprm->old_mm for setup_new_exec() to release outside the lock.
   */
- static int exec_mmap(struct mm_struct *mm, struct user_namespace *user_ns)
+ static int exec_mmap(struct linux_binprm *bprm)
  {
  	struct task_exec_state *exec_state __free(put_task_exec_state) = NULL;
+ 	struct mm_struct *mm = bprm->mm;
  	struct task_struct *tsk;
  	struct mm_struct *old_mm, *active_mm;
  	int ret;
  
- 	exec_state = alloc_task_exec_state(user_ns);
+ 	exec_state = alloc_task_exec_state(bprm->user_ns);
  	if (!exec_state)
  		return -ENOMEM;
  
@@@ -898,15 -900,22 +900,22 @@@
  	if (old_mm) {
  		mmap_read_unlock(old_mm);
  		BUG_ON(active_mm != old_mm);
- 		setmax_mm_hiwater_rss(&tsk->signal->maxrss, old_mm);
- 		mm_update_next_owner(old_mm);
- 		mmput(old_mm);
+ 		/* Defer teardown to setup_new_exec(), outside the exec locks. */
+ 		bprm->old_mm = old_mm;
  		return 0;
  	}
  	mmdrop_lazy_tlb(active_mm);
  	return 0;
  }
  
+ /* Release the address space replaced by exec, outside the exec locks. */
+ static void exec_mm_put_old(struct mm_struct *old_mm)
+ {
+ 	setmax_mm_hiwater_rss(&current->signal->maxrss, old_mm);
+ 	mm_update_next_owner(old_mm);
+ 	mmput(old_mm);
+ }
+ 
  static int de_thread(struct task_struct *tsk)
  {
  	struct signal_struct *sig = tsk->signal;
@@@ -1155,7 -1164,7 +1164,7 @@@ int begin_new_exec(struct linux_binprm 
  	 * Release all of the old mmap stuff
  	 */
  	acct_arg_size(bprm, 0);
- 	retval = exec_mmap(bprm->mm, bprm->user_ns);
+ 	retval = exec_mmap(bprm);
  	if (retval)
  		goto out;
  
@@@ -1338,6 -1347,12 +1347,12 @@@ void setup_new_exec(struct linux_binpr
  	me->mm->task_size = TASK_SIZE;
  	up_write(&me->signal->exec_update_lock);
  	mutex_unlock(&me->signal->cred_guard_mutex);
+ 
+ 	/* The exec locks are dropped: release the old address space now. */
+ 	if (bprm->old_mm) {
+ 		exec_mm_put_old(bprm->old_mm);
+ 		bprm->old_mm = NULL;
+ 	}
  }
  EXPORT_SYMBOL(setup_new_exec);
  
@@@ -1394,6 -1409,9 +1409,9 @@@ static void free_bprm(struct linux_binp
  		mutex_unlock(&current->signal->cred_guard_mutex);
  		abort_creds(bprm->cred);
  	}
+ 	/* exec swapped the mm but failed before setup_new_exec() freed it */
+ 	if (bprm->old_mm)
+ 		exec_mm_put_old(bprm->old_mm);
  	do_close_execat(bprm->file);
  	if (bprm->executable)
  		fput(bprm->executable);
diff --combined include/linux/binfmts.h
index a8379f4eee615,2c77e383e7375..0000000000000
--- a/include/linux/binfmts.h
+++ b/include/linux/binfmts.h
@@@ -25,6 -25,7 +25,7 @@@ struct linux_binprm 
  	struct page *page[MAX_ARG_PAGES];
  #endif
  	struct mm_struct *mm;
+ 	struct mm_struct *old_mm;	/* replaced address space, freed by setup_new_exec() */
  	/* user_ns published to task->exec_state at execve, narrowed by would_dump(). */
  	struct user_namespace *user_ns;
  	unsigned long p; /* current top of mem */
diff --combined kernel/exec_state.c
index 2b7d0262d0f4e,6034f4b4808fe..0000000000000
--- a/kernel/exec_state.c
+++ b/kernel/exec_state.c
@@@ -91,7 -91,7 +91,7 @@@ void task_exec_state_set_dumpable(enum 
  {
  	struct task_exec_state *exec_state;
  
- 	if (WARN_ON(value > TASK_DUMPABLE_ROOT))
+ 	if (WARN_ON_ONCE(value > TASK_DUMPABLE_ROOT))
  		value = TASK_DUMPABLE_OFF;
  
  	exec_state = rcu_dereference_protected(current->exec_state, true);
diff --combined kernel/ptrace.c
index ea8a682e837d9,d041645d9d17d..0000000000000
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@@ -53,11 -53,9 +53,9 @@@ bool ptracer_access_allowed(struct task
  {
  	const struct task_exec_state *es;
  
- 	if (!tsk->ptrace)
- 		return false;
- 	if (current != tsk->parent)
- 		return false;
  	guard(rcu)();
+ 	if (ptrace_parent(tsk) != current)
+ 		return false;
  	es = task_exec_state_rcu(tsk);
  	return READ_ONCE(es->dumpable) == TASK_DUMPABLE_OWNER ||
  	       ptracer_capable(tsk, es->user_ns);

On 5/28/26 10:28 AM, Mark Brown wrote:
> Hi all,
> 
> Today's linux-next merge of the vfs-brauner tree got conflicts in:
> 
>   kernel/ptrace.c
>   fs/exec.c
>   include/linux/binfmts.h
>   kernel/exec_state.c
> 
> between commits:
> 
>   6b1c66c9cca99 ("exec_state: relocate dumpable information")
>   38205ecbe6b6d ("exec: free the old mm outside the exec locks")
> 
> from the nfsd tree and commits:
> 
>   6b1c66c9cca99 ("exec_state: relocate dumpable information")
>   38205ecbe6b6d ("exec: free the old mm outside the exec locks")
> 
> from the vfs-brauner tree plus some other context from vfs-brauner
> merges.  Specifically this is due to the nfsd tree having a build break
> from the vfs-brauner tree it's based on and being held at an old version
> with it's old version of vfs-brauner while the vfs-brauner tree has been
> updated.  However since the build issue isn't fixed in the version of
> vfs-brauner I have today (I saw a patch on the list though, I guess this
> will be fixed tomorrow?) the below merge isn't actually going to be in
> -next, I'm merging the old version that's shared with nfsd and there's
> no actual conflict in today's tree.
> 
> Are you sure it's a good idea to base the nfsd tree on something
> that's rebasing?
Usually nfsd-next is based on a torvalds -rc tag. This time around,
Christian wanted to take some patches through the vfs tree that I need
for nfsd-7.2. Therefore I need to base nfsd-next on a branch that is a
merge of several vfs. topic branches plus the latest -rc tag.

vfs/vfs.all is the most convenient source of such a merged branch,
but it has proved unstable (yes, I was warned it might be!).

So I can think of a few alternate options:

1. I might create my own merged branch that grabs only the three vfs.
   branches I need. Cons: I've never done this before, I'm not certain
   my tool chain (StGit) supports git merge, and it tangles the merge
   graph even more than it already is.

2. I might drop the items in nfsd-next/testing that need the vfs.
   branches, and rebase nfsd-next on a torvalds -rc tag. Cons: that
   leaves the pre-requisites in vfs.all but they won't get an in-kernel
   consumer until v7.3

3. Maybe the only branch I need is the vfs.directory-delegation branch?
   I might rebase nfsd-next on that. But I still need -rc latest for
   patches in nfsd-testing to apply cleanly to nfsd-next.

Opinions are welcome! I'll start: I really dislike cross-tree
submission; it's a pain for everyone for not very much benefit. :-)


-- 
Chuck Lever

On Thu, May 28, 2026 at 10:51:58AM -0400, Chuck Lever wrote:

> 1. I might create my own merged branch that grabs only the three vfs.
>    branches I need. Cons: I've never done this before, I'm not certain
>    my tool chain (StGit) supports git merge, and it tangles the merge
>    graph even more than it already is.

You could always create this independently of your usual tooling and use
it as a base like something that someone else had created?  I don't know
StGit but I have similar stuff with my own tooling sometimes.

On 5/28/26 11:01 AM, Mark Brown wrote:
> On Thu, May 28, 2026 at 10:51:58AM -0400, Chuck Lever wrote:
> 
>> 1. I might create my own merged branch that grabs only the three vfs.
>>    branches I need. Cons: I've never done this before, I'm not certain
>>    my tool chain (StGit) supports git merge, and it tangles the merge
>>    graph even more than it already is.
> 
> You could always create this independently of your usual tooling and use
> it as a base like something that someone else had created?  I don't know
> StGit but I have similar stuff with my own tooling sometimes.

I've updated nfsd-next so it is based on a merge of the three
prerequisite vfs/ topic branches plus v7.1-rc5 using the mechanism you
suggested. Please give it a try.

-- 
Chuck Lever