From: Thomas Gleixner <tglx@linutronix.de>
To: Florian Albertz <linux@rlnm.net>, mingo@redhat.com
Cc: linux-kernel@vger.kernel.org,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: PROBLEM: Kernel 6.17 newly deadlocks futex
Date: Fri, 19 Dec 2025 21:07:13 +0100 [thread overview]
Message-ID: <873456b5hq.ffs@tglx> (raw)
In-Reply-To: <1d9fe0eb-11a0-4f8e-a8e7-57e1756193d3@app.fastmail.com>
On Fri, Dec 19 2025 at 11:02, Florian Albertz wrote:
> static int child(void *arg) {
> // It is important this call to create a thread happens between
> // the wait and wake calls.
> //
> // Due to the new behavior around `need_futex_hash_allocate_defaults`,
> // the first clone which includes CLONE_THREAD (CLONE_VM is not enough)
> // results in a change in how futex hashes are calculated.
The problem is not this one.
> clone(noop, malloc(STACK_SIZE) + STACK_SIZE,
> CLONE_VM | CLONE_SIGHAND | CLONE_THREAD, NULL, NULL, NULL);
>
> // So this now works with another hash and therefore does not wake the main
> // process.
> *fut = 1;
> syscall(SYS_futex, fut, FUTEX_WAKE_PRIVATE, 1, NULL, NULL, 0);
>
> return 0;
> }
>
> int main(int argc, char *argv[]) {
> fut = calloc(1, sizeof(*fut));
>
> // Now we create a new process sharing virtual memory but crucially without
> // specifying CLONE_THREAD.
The problem is here because the condition for hash allocation is too
tight. The private hash is bound to the MM which shared with CLONE_VM,
so the clone has to install a private hash despite creating a process
and not a thread.
> clone(child, malloc(STACK_SIZE) + STACK_SIZE, CLONE_VM, NULL, NULL, NULL);
>
> // And now this futex wait never wakes from kernel 6.17 onwards.
> syscall(SYS_futex, fut, FUTEX_WAIT_PRIVATE, 0, NULL, NULL, 0);
> }
The below should fix that. It's not completely correct because the
resulting hash sizing looks at current->signal->threads. As signal is
not shared each resulting process accounts for their own threads. Fixing
that needs some more thoughts.
Thanks,
tglx
---
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1948,11 +1948,9 @@ static void rv_task_fork(struct task_str
#define rv_task_fork(p) do {} while (0)
#endif
-static bool need_futex_hash_allocate_default(u64 clone_flags)
+static inline bool need_futex_hash_allocate_default(u64 clone_flags)
{
- if ((clone_flags & (CLONE_THREAD | CLONE_VM)) != (CLONE_THREAD | CLONE_VM))
- return false;
- return true;
+ return !!(clone_flags & CLONE_VM);
}
/*
next prev parent reply other threads:[~2025-12-19 20:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-19 10:02 PROBLEM: Kernel 6.17 newly deadlocks futex Florian Albertz
2025-12-19 20:07 ` Thomas Gleixner [this message]
2026-01-09 16:56 ` Sebastian Andrzej Siewior
2026-01-19 18:24 ` Florian Albertz
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=873456b5hq.ffs@tglx \
--to=tglx@linutronix.de \
--cc=bigeasy@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rlnm.net \
--cc=mingo@redhat.com \
--cc=peterz@infradead.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