From nobody Fri Oct 2 09:22:05 2026 Received: from canpmsgout11.his.huawei.com (canpmsgout11.his.huawei.com [113.46.200.226]) (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 C5D25364043 for ; Mon, 3 Aug 2026 10:23:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.226 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785752616; cv=none; b=lX5slEVS8jE5kEryc0lSz8zcF51vL7TzJu/KSvv7UkoWnjKBCih0qcqKc4eOlOyh7YYiMd1xTaPDVmtivoS26EjYyOWv1Jxrs9OgADFkHCACqAth4qs8tbKPkN7BmJ1LHJKV53YfcQkZfsPNYAjKzO8OCyIvcDc1V/cld1N9tPk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785752616; c=relaxed/simple; bh=Jd3UIxpkjMBpNn+5xWK4iuvU2LM77SbDOFRF5gXCZOM=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=cbRAAAldRR4gHfN+OrGkH1oWuQ1gnK4t5G7uLZUQUuExcqXAFTHmvZ2r70IUWEyOtzN8gUs+36k9Hxo6X6V6CO74sV/7hHD79NFc3c39riYuShGQMFcLWmV3uWozVigKHHd/x+M9T3DkjvcVxR/5aIid7HwhNa7SAaKzLAsMgPw= 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=OjnMu8PM; arc=none smtp.client-ip=113.46.200.226 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="OjnMu8PM" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=e5V7paWJDDIP6t4RQlt58b6RfwaZvMQ09bu6ZbWud1s=; b=OjnMu8PMYZDsM9yPOxZwnlAEnlNXz9/tk3nCkxnlbT6z437FIZLhd2cKWwUKneRXiv9LJRnSu MEBO/4TDsSBQk9kYcvKZ4Z1CrFUenBW5dWlWvtwDWrVYXPMY8jJR0XpkOXXO8obGPZ8SNZNqdGj dJZM4nxR4L0wJktaHImKfsQ= Received: from mail.maildlp.com (unknown [172.19.163.163]) by canpmsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4hDCF96kNWzKm4b; Mon, 3 Aug 2026 18:13:49 +0800 (CST) Received: from dggpemr500006.china.huawei.com (unknown [7.185.36.185]) by mail.maildlp.com (Postfix) with ESMTPS id 94C9A4048B; Mon, 3 Aug 2026 18:23:22 +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; Mon, 3 Aug 2026 18:23:21 +0800 From: Yao Kai To: , CC: , , , , , Subject: [PATCH] futex: Fix missed wakeup during private hash resize Date: Mon, 3 Aug 2026 18:43:13 +0800 Message-ID: <20260803104313.3393274-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: kwepems200001.china.huawei.com (7.221.188.67) 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. 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. Since a successful pivot does not notify waiters, the task can go to sleep after the only preceding wakeup has already been consumed. Wake waiters after every successful pivot. A full memory barrier before wake_up_var() pairs with set_current_state() in wait_var_event() and orders the completed pivot before the lockless waitqueue_active() check in wake_up_var(). The waiter therefore either observes hash_new =3D=3D NULL before sleeping or is made runnable. Fixes: bd54df5ea7ca ("futex: Allow to resize the private local hash") Cc: stable@vger.kernel.org Signed-off-by: Yao Kai --- kernel/futex/core.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/kernel/futex/core.c b/kernel/futex/core.c index 90fa9d886f752..3e030e117783a 100644 --- a/kernel/futex/core.c +++ b/kernel/futex/core.c @@ -220,6 +220,12 @@ static bool __futex_pivot_hash(struct mm_struct *mm, s= truct futex_private_hash * rcu_assign_pointer(mmph->hash, new); } kvfree_rcu(fph, rcu); + /* + * Pair with set_current_state() in wait_var_event(), as required by + * the lockless waitqueue_active() check in wake_up_var(). + */ + smp_mb(); + wake_up_var(mm); return true; } =20 --=20 2.34.1