From: Mark Brown <broonie@kernel•org>
To: Christian Brauner <brauner@kernel•org>,
Chuck Lever <chuck.lever@oracle•com>
Cc: Linux Kernel Mailing List <linux-kernel@vger•kernel.org>,
Linux Next Mailing List <linux-next@vger•kernel.org>
Subject: linux-next: manual merge of the vfs-brauner tree with the nfsd tree
Date: Thu, 28 May 2026 15:28:45 +0100 [thread overview]
Message-ID: <ahhRHXWXMtagI5Zi@sirena.org.uk> (raw)
[-- Attachment #1: Type: text/plain, Size: 5877 bytes --]
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(¤t->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(¤t->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);
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next reply other threads:[~2026-05-28 14:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-28 14:28 Mark Brown [this message]
2026-05-28 14:51 ` linux-next: manual merge of the vfs-brauner tree with the nfsd tree Chuck Lever
2026-05-28 15:01 ` Mark Brown
2026-05-28 15:34 ` Chuck Lever
-- strict thread matches above, loose matches on Subject: below --
2025-11-16 20:34 Stephen Rothwell
2025-12-02 23:11 ` Stephen Rothwell
2024-10-23 21:15 Stephen Rothwell
2024-02-07 0:41 Stephen Rothwell
2024-02-07 14:40 ` Chuck Lever
2024-02-07 14:58 ` Jeff Layton
2023-05-23 23:56 Stephen Rothwell
2023-05-24 9:08 ` Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ahhRHXWXMtagI5Zi@sirena.org.uk \
--to=broonie@kernel$(echo .)org \
--cc=brauner@kernel$(echo .)org \
--cc=chuck.lever@oracle$(echo .)com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox