From nobody Fri Apr 3 00:00:48 2026 Received: from silver.cherry.relay.mailchannels.net (silver.cherry.relay.mailchannels.net [23.83.223.166]) (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 876B94CB5B for ; Thu, 26 Mar 2026 00:25:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=23.83.223.166 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774484736; cv=pass; b=qbkrRwNqJPubZcYwkafmJhtiVO/k1qteMZxJlLHZrFqyhRYstTQN9Ozb4LKP6wCJBecUS/dFXC7a25Dou7rN7yTi7kvEHTSfGdlwIC7BR8EalxkkshT2+4IQWUwMEWjmCFTHc6vY9uDlsmS1or51sSwqAhdTETf3Nwm8WGHCWHA= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774484736; c=relaxed/simple; bh=7+q+b6HB9t+hBEOW/qiZkn5dhdanG7Nr52TQ1aIJOO8=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=HNi3T9C+mYzXb/nd/Nv8RG3Rw0hThhluv1CXh+60HQVzKIo2HGOebNAV2UHFosBV+eqUjb4VrFCq/AMaMv+vzj5B4zSusox9lGp/7kWlqO60YeBDzWv2Q1I77n5OoOXss67+3SXoVT9SNRzg+uRGouXyiRio5WKoTdMW3AY24y8= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=stgolabs.net; spf=fail smtp.mailfrom=stgolabs.net; dkim=pass (2048-bit key) header.d=stgolabs.net header.i=@stgolabs.net header.b=SWhsQ3LN; arc=pass smtp.client-ip=23.83.223.166 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=stgolabs.net Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=stgolabs.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=stgolabs.net header.i=@stgolabs.net header.b="SWhsQ3LN" X-Sender-Id: dreamhost|x-authsender|dave@stgolabs.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 1DE9A1227DE; Thu, 26 Mar 2026 00:18:08 +0000 (UTC) Received: from pdx1-sub0-mail-a222.dreamhost.com (100-114-133-131.trex-nlb.outbound.svc.cluster.local [100.114.133.131]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 5046E122287; Thu, 26 Mar 2026 00:18:05 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; d=mailchannels.net; s=arc-2022; cv=none; t=1774484286; b=lqiy0Dis1lwyr1lMGe+ef8RtAUBoW3VPaADdZ7lsoPnbx1ZtH/JPsD/yQJfPu/8E5jigqi 4vy+EUE/F8fa6pBrmjW7dzDbB0wLr6Ccxg9AQhZfIz3QXovQx2NLHG9U7QpgpEDtTSzrRt zbqHBXscLbOPO8zg5IjgwDbT+vO/bXaIk03W8k0umAwS1mboA9IhZuxlnuF9DC+ipMpmHD SEmexLQRC/MO1uTSZZZ13IbZIywaE7KOaF+Cl6oZ8BsOziwGsBZmlQJrCbIhAUobGiV8ur cU2+3l7yE95LI+lD4+q0Cz48Zd2HVr8wR6D3/HlKF2Ikzto+Di++1xlkORRi5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1774484286; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding:dkim-signature; bh=5rvqK9Kyt662ik1SPJmVvS4VdPvJ5qER+FHSuj5iZEg=; b=Iv1wG3q9gcv11XeNVlG6hC5YbazmoBp0Xp62dHGuas2cOPGVs08w5tgK5PLtMp8ddi8Rff yrdUIlKxfsRu6ox9cFCHn7JON+8MGpHYPcTIkh8TDAjZ+jNq/1gNLVRCYhvQiawIrjwDkY 1vh9029bgkrkKyC4nan/Qa7YevBeGRW0za+ELxYLyM9ixyN8nMcxkw6Pue3YmfwA+Sh3gn +jf+Pl2erwzMQqD8uKEtmRyjlKB8p7zTncdylnlxkoX9+Zyp5ghanWRDrPeyuWjZDe9OZy kXSaM6LpYm3dBCrtRdMjzyZMbfkSiNm14kWx4gbuO7+Q9pkUqANwhmVd9rLWIQ== ARC-Authentication-Results: i=1; rspamd-7f98bb5847-mrhwl; auth=pass smtp.auth=dreamhost smtp.mailfrom=dave@stgolabs.net X-Sender-Id: dreamhost|x-authsender|dave@stgolabs.net X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|dave@stgolabs.net X-MailChannels-Auth-Id: dreamhost X-Chemical-Inform: 0737507256a25fbb_1774484286792_425528917 X-MC-Loop-Signature: 1774484286791:3920766713 X-MC-Ingress-Time: 1774484286791 Received: from pdx1-sub0-mail-a222.dreamhost.com (sub3.homie.mail.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.114.133.131 (trex/7.1.5); Thu, 26 Mar 2026 00:18:06 +0000 Received: from offworld.lan (unknown [76.167.199.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: dave@stgolabs.net) by pdx1-sub0-mail-a222.dreamhost.com (Postfix) with ESMTPSA id 4fh49m4swSz16; Wed, 25 Mar 2026 17:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stgolabs.net; s=dreamhost; t=1774484285; bh=5rvqK9Kyt662ik1SPJmVvS4VdPvJ5qER+FHSuj5iZEg=; h=From:To:Cc:Subject:Date:Content-Transfer-Encoding; b=SWhsQ3LN0mB504jr6ukv/O+8VI3JKvXYGWNJlLUVk0oFtNAWMLTNQQpwrGGyCmPKJ XADB+nc97aJpErgFBysbW7LmXo/g3oV4GPuWv+2KMikGpUm+C8zVvZcLfi5GfccFLo mOlFId0bOHNm36HBNrXUn3EWFGHmaks8IHWBg5HE8oMjh0H4gKA2xdXZhXH0rG+CRE g3Cq9/zK5jTPfIcWpfJyyy2yOr2E4CcRxAWL55oQiuN4MBGW8l5ubRe20gyFMnYGmi HmOtBWOASDO7jBXSPEJOhbei9+QV56PyDzQqwJJoCHLBFKRD4VK3u4PKRUS0JxSam3 i1Ry9jvqShR1Q== From: Davidlohr Bueso To: tglx@kernel.org, mingo@redhat.com Cc: peterz@infradead.org, dvhart@infradead.org, andrealmeid@igalia.com, linux-kernel@vger.kernel.org, Davidlohr Bueso Subject: [PATCH v2 -tip] futex: Clear stale exiting pointer when pi-locking Date: Wed, 25 Mar 2026 17:17:59 -0700 Message-Id: <20260326001759.4129680-1-dave@stgolabs.net> X-Mailer: git-send-email 2.39.5 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Fuzzying/stressing futexes triggered: WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, C= PU#11: futex_lock_pi_s/524 When futex_lock_pi_atomic() sees the owner is exiting, it returns -EBUSY and stores a refcounted task pointer in 'exiting'. After wait_for_owner_exiting= () consumes that reference, the local pointer is never reset to nil. Upon a re= try, if futex_lock_pi_atomic() returns a different error, the bogus pointer is p= assed to wait_for_owner_exiting(). CPU0 CPU1 CPU2 futex_lock_pi(uaddr) // acquires the PI futex exit() futex_cleanup_begin() futex_state =3D EXITING futex_lock_pi(uaddr) futex_lock_pi_atomic() attach_to_pi_owner() // sees EXITING *exiting =3D owner // takes ref return -EBUSY wait_for_owner_exiting(-EBUSY, owner) put_task_struct() // drops ref // exiting still points to owner goto retry futex_lock_pi_atomic() lock_pi_update_atomic() cmpxchg(uaddr) *uaddr ^=3D WAITERS // whatever // value changed return -EAGAIN wait_for_owner_exiting(-EAGAIN, exiting) // stale WARN_ON_ONCE(exiting) Fix this by resetting upon retry, essentially aligning with requeue_pi. Fixes: 3ef240eaff36 ("futex: Prevent exit livelock") Signed-off-by: Davidlohr Bueso --- Changes from v1: updated splat in chagelog to non-hacked kernel (s/oh_my_fu= tex/wait_for_owner_exiting) kernel/futex/pi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/futex/pi.c b/kernel/futex/pi.c index 49ab5f40e86c..643199fdbe62 100644 --- a/kernel/futex/pi.c +++ b/kernel/futex/pi.c @@ -923,7 +923,7 @@ int fixup_pi_owner(u32 __user *uaddr, struct futex_q *q= , int locked) int futex_lock_pi(u32 __user *uaddr, unsigned int flags, ktime_t *time, in= t trylock) { struct hrtimer_sleeper timeout, *to; - struct task_struct *exiting =3D NULL; + struct task_struct *exiting; struct rt_mutex_waiter rt_waiter; struct futex_q q =3D futex_q_init; DEFINE_WAKE_Q(wake_q); @@ -938,6 +938,7 @@ int futex_lock_pi(u32 __user *uaddr, unsigned int flags= , ktime_t *time, int tryl to =3D futex_setup_timer(time, &timeout, flags, 0); =20 retry: + exiting =3D NULL; ret =3D get_futex_key(uaddr, flags, &q.key, FUTEX_WRITE); if (unlikely(ret !=3D 0)) goto out; --=20 2.39.5