From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-a1-smtp.messagingengine.com (fhigh-a1-smtp.messagingengine.com [103.168.172.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7943827280F for ; Fri, 19 Dec 2025 10:03:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.152 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766138602; cv=none; b=BzQnAxKWXpfH2AUCQxNsJ0bcwyIQ7CL9gPkFBYw8Hl90JiwR2piGQgNHGmnCUUAbXVKQgBxvQT/WcVecSs7UEmF5n+9eQGqwENsIkcA14Q5csOe9HmFep8Jmvq9uyub4yjoEwDQ9zpRqdNgRuhc2YNcfkbgX+dhS1OpmuPGJ+Ew= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766138602; c=relaxed/simple; bh=iddkubxydeOr4QRU+yL8P5XJy1bDeCww7gjl8ZEi6/g=; h=MIME-Version:Date:From:To:Cc:Message-Id:Subject:Content-Type; b=XVPFITBnbTcWYJ5jAbWTf9XIQ3DEjzE3T/HyW4EoZ8ywxOe2O/h9h0c3jS4UPCvFKIRBZ6B+8Itii2k7y7qTirEvWVbzgtDE55PqpyI3OOmVvg7AnXGzMNjzjAds3tDPLrdYPmsGIzBP8QkYoKl3qeoL0RngT1UjQmdKXPD7nWw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=rlnm.net; spf=pass smtp.mailfrom=rlnm.net; dkim=pass (2048-bit key) header.d=rlnm.net header.i=@rlnm.net header.b=e0B+5F14; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=XEPs/MiW; arc=none smtp.client-ip=103.168.172.152 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=rlnm.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rlnm.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rlnm.net header.i=@rlnm.net header.b="e0B+5F14"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="XEPs/MiW" Received: from phl-compute-08.internal (phl-compute-08.internal [10.202.2.48]) by mailfhigh.phl.internal (Postfix) with ESMTP id 7B44A1400095; Fri, 19 Dec 2025 05:03:19 -0500 (EST) Received: from phl-imap-15 ([10.202.2.104]) by phl-compute-08.internal (MEProxy); Fri, 19 Dec 2025 05:03:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rlnm.net; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:message-id:mime-version:reply-to :subject:subject:to:to; s=fm2; t=1766138599; x=1766224999; bh=Tu UshHmozXnyCggJZeXFeFnPZobD+IzYiCRwa0lH9sk=; b=e0B+5F14Ou2pbVTImV xeh5EU94ue9ExmxToYsk3WdXpp8fqqT1P46gO8EKqu+88wVbzRLHBrsBcxjJPZn4 JX4xv6QjYq+LChn7k+BzPtx7OG0Mk5V61EjfATX+iqib+CZ1K9LlYDzqF8FC/+j0 Y3BEngB6J+xe+pqRynWUf7xQbzMfayhnhK80EqlpJKMS8Kwqh9f+5sS00ltD4GfC CiNmJ3AWyHy5wn5+0ED1M/mqtdLrhpT8qpacivTqsY4nZ94g+wxyMDfIU2OnpGPq BkjQY+LFcZRQ04M8GnuE/wfgxR/E5pgAkoeR3bWcb/QTC0GEfFczjedr0J4GBAUb zRDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:message-id:mime-version:reply-to:subject :subject:to:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1766138599; x=1766224999; bh=TuUshHmozXnyCggJZeXFeFnPZobD +IzYiCRwa0lH9sk=; b=XEPs/MiWdGEjOCMu0Ne7RBF8/2EYaXetPFrBbUDO5moR bzwUffS8G+ylPHH5fdIXNMWd1OLgKqNaDgg/6L5r+mLkYPAuvbLyO1rEdh+8jHay xT7nrtW5ODmPR+sfP6SeskHBNOFoCyoWDBLaU0znEKyN2ss8zxmAN+3OOQbK8Ooj ND4svzC/tZHi8Dy1BWQ4ybLdW+ENqwZlNLj+Uo6C9YulgGbg9IBa2ZPPbXTtRfKZ yGzPfcYDEJg+xD7WnoaqHp/Moili6Yo2hqqJtlVkwuLQIZ/wMVIS/yTWsilHN0qf sHXcAVCSyKbjdMtXls5KFLCvgnzpS6BTzU62l6WKKA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdegkedttdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecunecujfgurhepofggfffhvfevkffutgfgsehtjeertdertd dtnecuhfhrohhmpedfhfhlohhrihgrnhcutehlsggvrhhtiidfuceolhhinhhugiesrhhl nhhmrdhnvghtqeenucggtffrrghtthgvrhhnpedvhfdtveffheejgfdvvdegteegvdehud elleeuhfffheevteeflefhffevgfdtieenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehlihhnuhigsehrlhhnmhdrnhgvthdpnhgspghrtghpth htohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepthhglhigsehlihhnuhht rhhonhhigidruggvpdhrtghpthhtohepmhhinhhgohesrhgvughhrghtrdgtohhmpdhrtg hpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhg X-ME-Proxy: Feedback-ID: ia99e48bb:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 4E45878006C; Fri, 19 Dec 2025 05:03:19 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: ArNNUgofnt-V Date: Fri, 19 Dec 2025 11:02:59 +0100 From: "Florian Albertz" To: tglx@linutronix.de, mingo@redhat.com Cc: linux-kernel@vger.kernel.org Message-Id: <1d9fe0eb-11a0-4f8e-a8e7-57e1756193d3@app.fastmail.com> Subject: PROBLEM: Kernel 6.17 newly deadlocks futex Content-Type: text/plain Content-Transfer-Encoding: 7bit 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 #include #include #include #include #include #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.