From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 8761E366806 for ; Tue, 4 Aug 2026 12:21:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785846110; cv=none; b=OGPYkR136k0rf9ttJcUN2rf9MpjsnD48D4Pbc65byfw8b/c1KhSYRpEimzjwAzuYnHdFykf6pQfA9II79jb2f6+qbV2ckSi8YeksL1sdkQSreKqNBipmgvsiiJ9bY4VKc/bkcrRe+1Yic9jVmEciI/5y9FpYqdtC29T8SX32jIg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785846110; c=relaxed/simple; bh=XK/rFMKxmVh9Z5muBMNletXoa91PvyA5migzQnt/0Rc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=DkIMJ2X5gKWQ+NJf4IpTYHJotOwYbuaUhnszbHmjPcIRUDveXAyLgdhVoHffc25yeOoFWzPryr3fns1A/twyvGegFrPIuMaFw7waZNqAAXIzfo938uooWKR41wEHYZ0NjkCVjuIN15DIBohYrCiB0u4I4R1XzsdoRfQY4YVu654= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=j4bFiv4D; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="j4bFiv4D" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=V/xBbIQ0/qLKivoTd3gf8hXFQAGyGVNvYEFVLqeGhHI=; b=j4bFiv4DrdfAHyE6GLKyzyOOck fPGWLS2XKYeryKNbi9nJxRnmO/of6/NGQJCc/WZdFpKYWnzk1pcE5PwLqYMpDXO9YJWUaIxgfLpbe yg1m4yJJbS4BVb6CFR2NwX4bTCuddGsAx4wFw35DWok8KNm0Z+BTNCdkaJ8JJeCMj9wz5GkTW3QrD 8kcqxPFYlWTWpKYrLrp1ZcVM1BST7vDrxjwxacjnE0RPHwxwl+VUBnfam1ujDJdnxO7KpqZVLvPMU QldQhLuJ7oX/mWNuhMkpTqOwDJXgwicOXm7adtK4bgZKNwWhJSaFf0c6tuNi2+h4dVp/sR30IxsYT 5O41maRQ==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.99.2 #2 (Red Hat Linux)) id 1wrE9I-00000009sRl-3DqW; Tue, 04 Aug 2026 12:21:36 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id A2EEC30063F; Tue, 04 Aug 2026 14:21:02 +0200 (CEST) Date: Tue, 4 Aug 2026 14:21:02 +0200 From: Peter Zijlstra To: Yao Kai Cc: linux-kernel@vger.kernel.org, tglx@kernel.org, mingo@redhat.com, dvhart@infradead.org, dave@stgolabs.net, andrealmeid@igalia.com, bigeasy@linutronix.de, liuyongqiang13@huawei.com Subject: Re: [PATCH v2 1/2] futex/requeue: Fix rtmutex schedule preparation for requeue PI Message-ID: <20260804122102.GI776954@noisy.programming.kicks-ass.net> References: <20260722085140.1949077-1-yaokai34@huawei.com> <20260722085140.1949077-2-yaokai34@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260722085140.1949077-2-yaokai34@huawei.com> On Wed, Jul 22, 2026 at 04:51:39PM +0800, Yao Kai wrote: > A waiter requeued onto a PI futex can reach rt_mutex_wait_proxy_lock() > without rtmutex schedule preparation: > > WARNING: CPU: 0 PID: 293 at kernel/sched/core.c:7606 > RIP: rt_mutex_schedule+0x43/0x50 > Call Trace: > rt_mutex_slowlock_block.constprop.0+0x5b/0x320 > rt_mutex_wait_proxy_lock+0x3e/0x80 > futex_wait_requeue_pi+0x3ba/0x590 > do_futex+0x171/0x1f0 > > rt_mutex_schedule() requires current->sched_rt_mutex to be set. Normally, > rt_mutex_pre_schedule() sets it before an rtmutex waiter can schedule. With > requeue PI, another task can enqueue the waiter after its futex_q becomes > visible: > > waiter requeue task > ------ ------------ > futex_wait_requeue_pi() > futex_wait_setup() > futex_queue(&q) > futex_requeue() > rt_mutex_start_proxy_lock() > enqueue rt_waiter > install pi_blocked_on > requeue_futex() > plist_del(&q->list) > futex_do_wait() > plist_node_empty(&q->list) > skip schedule() > plist_add(&q->list) > futex_requeue_pi_complete() > IN_PROGRESS -> DONE > futex_requeue_pi_wakeup_sync() // DONE > rt_mutex_wait_proxy_lock() > rt_mutex_schedule() > > futex_do_wait() mistakes the temporary removal for a wakeup and skips > schedule(). The proxy waiter can nevertheless remain blocked on the target > rtmutex and subsequently enter rt_mutex_schedule() with > current->sched_rt_mutex clear. > > Call rt_mutex_pre_schedule() and rt_mutex_post_schedule() directly around > rt_mutex_wait_proxy_lock() so this second blocking point has the required > scheduler preparation. > > Fixes: d14f9e930b90 ("locking/rtmutex: Use rt_mutex specific scheduler helpers") > Suggested-by: Sebastian Andrzej Siewior > Cc: stable@vger.kernel.org > Signed-off-by: Yao Kai > --- > kernel/futex/requeue.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/kernel/futex/requeue.c b/kernel/futex/requeue.c > index 79823ad13683..f7889fb2fce4 100644 > --- a/kernel/futex/requeue.c > +++ b/kernel/futex/requeue.c > @@ -1,6 +1,7 @@ > // SPDX-License-Identifier: GPL-2.0-or-later > > #include > +#include > #include > > #include "futex.h" > @@ -865,7 +866,14 @@ int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags, > case Q_REQUEUE_PI_DONE: > /* Requeue completed. Current is 'pi_blocked_on' the rtmutex */ > pi_mutex = &q.pi_state->pi_mutex; > + /* > + * Requeue temporarily removes q from the hash bucket, so > + * futex_do_wait() may skip schedule() even though the proxy > + * waiter still has to block on the rtmutex. > + */ > + rt_mutex_pre_schedule(); > ret = rt_mutex_wait_proxy_lock(pi_mutex, to, &rt_waiter); > + rt_mutex_post_schedule(); As per always, I'm totally confused about everything. I mean, futexes suck, but requeue sucks worse. So the purpose of rt_mutex_pre_schedule() was to avoid the double waiter enqueue for rt_mutex on RT, where sched_submit_work() will hit a spinlock-nee-rtlock. So rt_mutex_pre_schedule() must happen before the rt_mutex is added as a waiter. However, AFAICT we're already a waiter at the above spot, no? So this cannot be right. The changelogs doesn't at all explain why this is correct. Please help?