From: Thomas Gleixner <tglx@kernel.org>
To: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>,
"André Almeida" <andrealmeid@igalia.com>
Cc: linux-kernel@vger.kernel.org, Carlos O'Donell <carlos@redhat.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Florian Weimer <fweimer@redhat.com>,
Rich Felker <dalias@aerifal.cx>,
Torvald Riegel <triegel@redhat.com>,
Darren Hart <dvhart@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Davidlohr Bueso <dave@stgolabs.net>,
Arnd Bergmann <arnd@arndb.de>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>
Subject: Re: [RFC PATCH] futex: Introduce __vdso_robust_futex_unlock
Date: Tue, 17 Mar 2026 00:29:17 +0100 [thread overview]
Message-ID: <87jyvbnyk2.ffs@tglx> (raw)
In-Reply-To: <2c8b81cf-af1d-44ba-9a4d-d033a8ddb2a1@efficios.com>
On Mon, Mar 16 2026 at 18:30, Mathieu Desnoyers wrote:
> On 2026-03-16 18:19, Thomas Gleixner wrote:
>> What I clearly described is the sequence:
>>
>> set_pointer();
>> unlock();
>> sys_exit();
>>
>> The kernel does not care about that at all as that's what user space
>> asked for. That is clearly in the category of "I want to shoot myself
>> into the foot".
>>
>> The only case where the kernel has to provide help to user space is the
>> involuntary exit caused by a crash or external signal between unlock()
>> and clear_pointer(). Simply because there is no way that user space can
>> solve that problem on its own.
>>
>> If you want to prevent user space from shooting itself into the foot
>> then the above crude scenario is the least of your problems.
>
> So the extra scenario I am concerned about is:
>
> Thread A Thread B
> ----------------------------------------
> set_pointer();
> unlock();
> syscall exit_group(2)
>
> This does not fall under the "async" program termination per se, because
> it is issued by Thread B, but it's not the result of an "exit(2)" call
> from Thread A.
>
> Is this scenario too far fetched, or something we should care about ?
It's a legit scenario, but you still fail to try to look at the code and
understand how all of this works even after I gave you enough hints.
I'm truly amazed that you even failed to ask any AI agent the obvious
question:
"When a task invokes the exit_group syscall on Linux how does the
Linux kernel manage to tear down all tasks which belong to the same
process?"
Both agents which https://arena.ai randomly picked out for me provided
very comprehensive explanations. Let me paste you one of them:
"3. Terminate All Other Threads
do_group_exit calls zap_other_threads, which:
Iterates over all tasks in the thread group using for_each_thread
(traversing the thread group list in task_struct). Sends an
uncatchable SIGKILL signal to every thread except the current one
(using SEND_SIG_FORCED to bypass any signal blocking). Since SIGKILL
cannot be caught or ignored, these threads will terminate
immediately."
If that's not a sufficient answer for you, may I recommed to look at:
https://training.linuxfoundation.org/
Thanks,
tglx
next prev parent reply other threads:[~2026-03-16 23:29 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-11 18:54 [RFC PATCH] futex: Introduce __vdso_robust_futex_unlock Mathieu Desnoyers
2026-03-11 20:11 ` Mathieu Desnoyers
2026-03-12 8:49 ` Florian Weimer
2026-03-12 13:13 ` Mathieu Desnoyers
2026-03-12 14:12 ` Florian Weimer
2026-03-12 14:14 ` André Almeida
2026-03-12 16:09 ` Mathieu Desnoyers
2026-03-12 13:46 ` André Almeida
2026-03-12 14:04 ` Mathieu Desnoyers
2026-03-12 18:40 ` Mathieu Desnoyers
2026-03-12 18:58 ` André Almeida
2026-03-12 19:10 ` Thomas Gleixner
2026-03-12 19:16 ` Mathieu Desnoyers
2026-03-13 8:20 ` Florian Weimer
2026-03-12 20:19 ` Thomas Gleixner
2026-03-12 21:28 ` Mathieu Desnoyers
2026-03-12 22:23 ` Thomas Gleixner
2026-03-12 22:52 ` Mathieu Desnoyers
2026-03-13 12:12 ` Sebastian Andrzej Siewior
2026-03-13 12:17 ` Mathieu Desnoyers
2026-03-13 13:29 ` Sebastian Andrzej Siewior
2026-03-13 13:35 ` Mathieu Desnoyers
2026-03-16 17:12 ` Thomas Gleixner
2026-03-16 19:36 ` Mathieu Desnoyers
2026-03-16 20:27 ` Thomas Gleixner
2026-03-16 21:01 ` Mathieu Desnoyers
2026-03-16 22:19 ` Thomas Gleixner
2026-03-16 22:30 ` Mathieu Desnoyers
2026-03-16 23:29 ` Thomas Gleixner [this message]
2026-03-20 18:13 ` Mathieu Desnoyers
2026-03-24 21:35 ` Thomas Gleixner
2026-03-25 14:12 ` Mathieu Desnoyers
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=87jyvbnyk2.ffs@tglx \
--to=tglx@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=andrealmeid@igalia.com \
--cc=arnd@arndb.de \
--cc=bigeasy@linutronix.de \
--cc=carlos@redhat.com \
--cc=dalias@aerifal.cx \
--cc=dave@stgolabs.net \
--cc=dvhart@infradead.org \
--cc=fweimer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=triegel@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.