From: Oleg Nesterov <oleg@redhat.com>
To: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-kselftest@vger.kernel.org, linux-mm@kvack.org,
linux-security-module@vger.kernel.org
Subject: Re: [RFC PATCH 2/3] exec: don't wait for zombie threads with cred_guard_mutex held
Date: Mon, 10 Nov 2025 16:09:05 +0100 [thread overview]
Message-ID: <aRIAEYH2iLLN-Fjg@redhat.com> (raw)
In-Reply-To: <aRHFSrTxYSOkFic7@grain>
Hi Cyrill,
On 11/10, Cyrill Gorcunov wrote:
>
> On Sun, Nov 09, 2025 at 06:15:33PM +0100, Oleg Nesterov wrote:
> ..
> > static int kill_sub_threads(struct task_struct *tsk)
> > {
> > struct signal_struct *sig = tsk->signal;
> > int err = -EINTR;
> >
> > read_lock(&tasklist_lock);
> > spin_lock_irq(&tsk->sighand->siglock);
> > if (!((sig->flags & SIGNAL_GROUP_EXIT) || sig->group_exec_task)) {
> > sig->group_exec_task = tsk;
> > sig->notify_count = -zap_other_threads(tsk);
>
> Hi Oleg! I somehow manage to miss a moment -- why negative result here?
You know, initially I wrote
sig->notify_count = 0 - zap_other_threads(tsk);
to make it clear that this is not a typo ;)
This is for exit_notify() which does
/* mt-exec, de_thread() -> wait_for_notify_count() */
if (tsk->signal->notify_count < 0 && !++tsk->signal->notify_count)
wake_up_process(tsk->signal->group_exec_task);
Then setup_new_exec() sets notify_count > 0 for __exit_signal() which does
/* mt-exec, setup_new_exec() -> wait_for_notify_count() */
if (sig->notify_count > 0 && !--sig->notify_count)
wake_up_process(sig->group_exec_task);
Yes this needs more comments and (with or without this patch) cleanups.
Note that exit_notify() and __exit_signal() already (before this patch)
use ->notify_count almost the same way, just exit_notify() assumes that
notify_count < 0 means the !thread_group_leader() case in de_thread().
Oleg.
next prev parent reply other threads:[~2025-11-10 15:09 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-17 12:23 [PATCH v10] exec: Fix dead-lock in de_thread with ptrace_attach Bernd Edlinger
2021-07-11 17:43 ` [PATCH v11] " Bernd Edlinger
2023-10-30 5:20 ` [PATCH v12] " Bernd Edlinger
2023-10-30 9:00 ` kernel test robot
2023-11-06 6:41 ` [PATCH v13] " Bernd Edlinger
2024-01-15 19:22 ` [PATCH v14] " Bernd Edlinger
2024-01-15 19:37 ` Matthew Wilcox
2024-01-17 9:51 ` Bernd Edlinger
2024-01-16 15:22 ` Oleg Nesterov
2024-01-17 15:07 ` Bernd Edlinger
2024-01-17 16:38 ` Oleg Nesterov
2024-01-22 13:24 ` Bernd Edlinger
2024-01-22 13:44 ` Oleg Nesterov
2024-01-22 21:30 ` Kees Cook
2024-01-23 18:30 ` Bernd Edlinger
2024-01-24 0:09 ` Kees Cook
2024-01-22 18:31 ` [PATCH v15] " Bernd Edlinger
2025-08-18 6:04 ` Jain, Ayush
2025-08-18 20:53 ` [PATCH v16] " Bernd Edlinger
2025-08-19 4:36 ` Kees Cook
2025-08-19 18:53 ` Bernd Edlinger
2025-08-21 17:34 ` [PATCH v17] " Bernd Edlinger
2025-10-27 6:26 ` Bernd Edlinger
2025-10-27 12:06 ` Peter Zijlstra
2025-11-02 16:17 ` Oleg Nesterov
2025-11-05 14:32 ` Oleg Nesterov
2025-11-11 9:21 ` Christian Brauner
2025-11-11 11:07 ` Bernd Edlinger
2025-11-11 13:12 ` Oleg Nesterov
2025-11-11 13:45 ` Bernd Edlinger
2025-11-12 9:52 ` Oleg Nesterov
2025-11-17 6:31 ` Bernd Edlinger
2025-11-17 15:01 ` Oleg Nesterov
2025-11-17 20:08 ` Bernd Edlinger
2025-11-09 17:14 ` [RFC PATCH 0/3] mt-exec: fix deadlock with ptrace_attach() Oleg Nesterov
2025-11-09 17:14 ` [RFC PATCH 1/3] exec: make setup_new_exec() return int Oleg Nesterov
2025-11-09 17:15 ` [RFC PATCH 2/3] exec: don't wait for zombie threads with cred_guard_mutex held Oleg Nesterov
2025-11-10 10:58 ` Cyrill Gorcunov
2025-11-10 15:09 ` Oleg Nesterov [this message]
2025-11-10 21:49 ` Cyrill Gorcunov
2025-11-11 14:09 ` Oleg Nesterov
2025-11-09 17:16 ` [RFC PATCH 3/3] ptrace: ensure PTRACE_EVENT_EXIT won't stop if the tracee is killed by exec Oleg Nesterov
2025-11-10 5:28 ` [RFC PATCH 0/3] mt-exec: fix deadlock with ptrace_attach() Bernd Edlinger
2025-11-10 14:47 ` Oleg Nesterov
2025-11-18 18:13 ` [PATCH v18] exec: Fix dead-lock in de_thread with ptrace_attach Bernd Edlinger
2025-11-20 15:15 ` Eric W. Biederman
2025-11-20 17:29 ` Eric W. Biederman
2025-11-20 20:57 ` [RFC][PATCH] exec: Move cred computation under exec_update_lock Eric W. Biederman
2025-11-20 23:50 ` Eric W. Biederman
2025-11-21 2:59 ` Bernd Edlinger
2025-11-21 7:18 ` Eric W. Biederman
2025-11-21 9:35 ` Bernd Edlinger
2025-11-21 11:26 ` Bernd Edlinger
2025-11-21 19:19 ` Eric W. Biederman
2025-11-21 23:06 ` Ryan Lee
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=aRIAEYH2iLLN-Fjg@redhat.com \
--to=oleg@redhat.com \
--cc=gorcunov@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).