From: "Florian Albertz" <linux@rlnm.net>
To: tglx@linutronix.de, mingo@redhat.com
Cc: linux-kernel@vger.kernel.org
Subject: PROBLEM: Kernel 6.17 newly deadlocks futex
Date: Fri, 19 Dec 2025 11:02:59 +0100 [thread overview]
Message-ID: <1d9fe0eb-11a0-4f8e-a8e7-57e1756193d3@app.fastmail.com> (raw)
Hi everyone,
a program of mine started deadlocking in kernel 6.17 due to hanging in a
FUTEX_WAIT_PRIVATE call.
Now first off, due to factors outside of my control, I am using futexes with
the FUTEX_PRIVATE_FLAG while also working with child processes which aren't
spawned with CLONE_THREAD. They are however created with CLONE_VM.
This did work before (and works now, excluding the specific edge case demonstrated
below), but I would understand this not being fixed as FUTEX_PRIVATE_FLAG
is documented to be specifically about threaded programs. I would be very happy
if the previous behaviour could be restored though. Ideally with FUTEX_PRIVATE_FLAG
being documented to work as long as processes run in the same memory space.
But about the actual deadlock. The following program completes execution on
a released 6.16.10 kernel on x86_64. On kernel 6.17.9 as well as 6.18.1 it deadlocks.
Tested kernels are from the official archlinux repositories:
---
#define _GNU_SOURCE
#include <linux/futex.h>
#include <sched.h>
#include <stdint.h>
#include <stdlib.h>
#include <sys/syscall.h>
#include <unistd.h>
#define STACK_SIZE (1024 * 1024)
static uint32_t *fut;
static int noop(void *arg) { return 0; }
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.
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.
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);
}
---
I realise for a fully reliable reproduction there would probably be more synchronization required,
but I hope the above is enough to demonstrate the problem. Same goes for error handling etc.
Also apologies for any other things causing confusion with the above code, I think this
reproduction may be the first C code I have written in years.
The issue does not occur if any process with CLONE_THREAD was created before the wait.
It does not occur if no process with CLONE_THREAD is created at all. And the code also
works as expected if the FUTEX_PRIVATE_FLAG is omitted.
Thank you for your time and work on the kernel, I'll gladly provide any further info you need.
Greetings and happy holidays,
Florian A.
next reply other threads:[~2025-12-19 10:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-19 10:02 Florian Albertz [this message]
2025-12-19 20:07 ` Thomas Gleixner
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=1d9fe0eb-11a0-4f8e-a8e7-57e1756193d3@app.fastmail.com \
--to=linux@rlnm.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
/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
all inboxes | Powered by JetHome®