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 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.