From nobody Fri Oct 2 06:17:35 2026 Received: from canpmsgout12.his.huawei.com (canpmsgout12.his.huawei.com [113.46.200.227]) (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 297F8345749 for ; Tue, 4 Aug 2026 12:35:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.227 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785846939; cv=none; b=Um/HBXiFZpAmkTj6b3rIqd3V58Lf4DQfzf6wHFNjjYKJpBN5DNgYiGiLVLnSGk9xs+kkkzi/6cK+ltY/Im2jd8TmzdL4Z+TF5QMaZd9cQRn8ZXm4/aQT/iLIvltk++2zmpyp+CSDPuCJeI8JDSkQmQUE2aPXkL5ni0LxM5fhbz0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785846939; c=relaxed/simple; bh=0PaCz62wTNmYIAJs7Xd4ieeITQosgkl3fkXUGUvKkhE=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=FYWWfJv8wIgb9CQZSVNKzteAFaQEdzv+fe8UP0F2ewQcdG2QZ889qe2W7yDaamaVDlwG5wEOMcwuSj5IMbE5qcATE9GAbDsEp4ZKC2SJk9DFDE1C+B+OFa1Nrysyn6HGu1CrtRBYaL042CM4aqxE1LGcrW1AQAST/DeJxq8QJUY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=fhi1Qiuh; arc=none smtp.client-ip=113.46.200.227 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="fhi1Qiuh" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=JReDc938hRb0WCkwOK2PwhzxJZJ5ESdVg2C3SwU/mv0=; b=fhi1QiuhL8Zz7eZ41pwDb7mDpWI42Z7y76YMmFvHiVg231kLu+O7oTD+O8b0kVLLABbYzdJ7G /eLnLp7d6pjyxS4k6fCvDpct2NlFiOQuMvpbOUcySmS2fgwvzFDa0x3/TJlKFlLJGLcK8Eix6/f CmR12k7hxY3z3WS1xMM4avQ= Received: from mail.maildlp.com (unknown [172.19.163.127]) by canpmsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4hDt6755mZznTts; Tue, 4 Aug 2026 20:25:03 +0800 (CST) Received: from dggpemr500006.china.huawei.com (unknown [7.185.36.185]) by mail.maildlp.com (Postfix) with ESMTPS id B4AC7402AB; Tue, 4 Aug 2026 20:35:30 +0800 (CST) Received: from localhost.localdomain (10.50.85.180) by dggpemr500006.china.huawei.com (7.185.36.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 4 Aug 2026 20:35:30 +0800 From: Yao Kai To: , CC: , , , , , Subject: [PATCH v2] futex: Fix race in futex_pivot_pending() during private hash resize Date: Tue, 4 Aug 2026 20:55:30 +0800 Message-ID: <20260804125530.3933754-1-yaokai34@huawei.com> X-Mailer: git-send-email 2.43.0 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 X-ClientProxiedBy: kwepems500001.china.huawei.com (7.221.188.70) To dggpemr500006.china.huawei.com (7.185.36.185) Content-Type: text/plain; charset="utf-8" A task performing a custom private hash resize can remain blocked in uninterruptible sleep indefinitely. The hung-task detector reports: INFO: task futex-resizer:314 blocked for more than 10 seconds. task:futex-resizer state:D stack:14824 pid:314 tgid:312 ppid:311 Call Trace: __schedule+0x521/0xf30 schedule+0x22/0xa0 futex_hash_allocate+0x3db/0x490 __do_sys_prctl+0x6f5/0xbd0 do_syscall_64+0xf9/0x530 entry_SYSCALL_64_after_hwframe+0x77/0x7f Kernel panic - not syncing: hung_task: blocked tasks futex_pivot_pending() allows the resize request to continue when either no replacement hash is pending (hash_new =3D=3D NULL) or the current hash reference count has reached zero. After the final-reference wake, another futex task can complete the pivot between the two observations: T1 T2 futex_hash_allocate() wait_var_event(mm, ...) futex_pivot_pending(mm) hash_new !=3D NULL futex_hash() futex_ref_get(old) -> false futex_pivot_hash(mm) hash_new =3D NULL __futex_pivot_hash(mm, new) rcu_assign_pointer(hash, new) fph =3D rcu_dereference(hash) /* new */ futex_ref_is_dead(fph) -> false schedule() The pivot changes the state from hash_new !=3D NULL with a dead current hash to hash_new =3D=3D NULL with a live current hash. Because futex_pivot_pending() reads hash_new and hash without serialization, the resize task can observe hash_new in the pre-pivot state and hash in the post-pivot state, causing futex_pivot_pending() to return false even though the pivot has completed. The task then goes to sleep after the wakeup has already been consumed. Serialize state reads in futex_pivot_pending() using futex_mm_phash::lock. This guarantees that futex_pivot_pending() observes hash_new and hash atomically, eliminating the race condition. Fixes: bd54df5ea7ca ("futex: Allow to resize the private local hash") Suggested-by: Peter Zijlstra Cc: stable@vger.kernel.org Signed-off-by: Yao Kai --- kernel/futex/core.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/kernel/futex/core.c b/kernel/futex/core.c index 179b26e9c934..c3299c5aee63 100644 --- a/kernel/futex/core.c +++ b/kernel/futex/core.c @@ -1752,14 +1752,15 @@ void futex_hash_free(struct mm_struct *mm) =20 static bool futex_pivot_pending(struct mm_struct *mm) { + struct futex_mm_phash *mmph =3D &mm->futex.phash; struct futex_private_hash *fph; =20 - guard(rcu)(); + guard(mutex)(&mmph->lock); =20 - if (!mm->futex.phash.hash_new) + if (!mmph->hash_new) return true; =20 - fph =3D rcu_dereference(mm->futex.phash.hash); + fph =3D rcu_dereference_raw(mmph->hash); return futex_ref_is_dead(fph); } =20 --=20 2.43.0