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 96978426D37 for ; Mon, 24 Aug 2026 13:23: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=1787577834; cv=none; b=QNF+uFwAfsCGe6w/rajX/VTABgxkRYUf7qVGzkdWU+9HJZRMcBP+w9jaufjEf62SfKe00qy9hp/3+tNcRLDQwvpLOorHuKf9euD78xpv0mzS7yQFXTnMTLDcLKZCnyZFDZBh0ASdewuR1pJ7dA/bQxrU0AhVwZd5FSzTvv8gD2o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787577834; c=relaxed/simple; bh=SUf57nUKgpRNUrhqptH0syLujib6Gq7TPXMV8XAmSKc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ne5+vqeIeGo5GIr/0zpBVDNJtU+d2+LwR3eBY7bnqRZB2ST5nI9HIFBmiNjVcqXmFVNeiooRf2tgPsjSxdIC15Z7mPVrxGjeQ3untREqzcXUcQe6RYcdbbx0cOMUrTagPY6NxCmt2YXH42ZXE7fkNMOks40NHo8Y/rvLXGJjMDE= 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=fqVP9Vf9; 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="fqVP9Vf9" 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=96fBle7Vws1Tuvs+QVRfPpk1OMnH8NmGpbHfgiV/GXM=; b=fqVP9Vf9qv+MrbiAJB1BMxI70u oZhdlHDmQUhqx+4LYqSzjSpufqWPlvVZ3iZJ+hkGSAjkCJm4f8Y5XQoOKmVySoKnhX3Lo03GVidux AkCsGgUbaLV5/qGn2hb1niJFMhYYn2zmIn/uNodO3Vr8jzWdn5GpiTeolOJSmwgKvBcrHE8Lh23aT zMFGXKt4kYQehblbtlIXWfu8JyKMz9PORNQZ/BJZ2W42kA5GVq4LnGDIYr8wBYT2yPvWakfGlsIuj xUcdXEFH77mf6FN2gqDfVj1NIOq/1IQANbgpm9QZyt4JA3wUkwjn6k1ErWkihG1M7N4CfmR6U/9Ks BqeHzVYA==; 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 1wyUeF-00000005EB1-4Awu; Mon, 24 Aug 2026 13:23:36 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 7686F300244; Mon, 24 Aug 2026 15:23:34 +0200 (CEST) Date: Mon, 24 Aug 2026 15:23:34 +0200 From: Peter Zijlstra To: Sebastian Andrzej Siewior Cc: linux-kernel@vger.kernel.org, =?iso-8859-1?Q?Andr=E9?= Almeida , Darren Hart , Davidlohr Bueso , Ingo Molnar , Thomas Gleixner , Borislav Petkov , Yao Kai Subject: Re: [PATCH v3 1/2] futex: Add missing rt_mutex_.*_schedule() around rt_mutex_wait_proxy_lock() Message-ID: <20260824132334.GI687043@noisy.programming.kicks-ass.net> References: <20260824125544.2353006-1-bigeasy@linutronix.de> <20260824125544.2353006-2-bigeasy@linutronix.de> 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: <20260824125544.2353006-2-bigeasy@linutronix.de> On Mon, Aug 24, 2026 at 02:55:42PM +0200, Sebastian Andrzej Siewior wrote: > From: Yao Kai > > A waiter requeued onto a PI futex can reach rt_mutex_wait_proxy_lock() > without rtmutex schedule preparation, triggering the lockdep_assert() in > rt_mutex_schedule(). > The lack of it, can be seen with requeue PI, multiple waiters and > requeing multiple tasks, the subsequent requeued task can be requeued in > the state Q_REQUEUE_PI_DONE: > > waiter requeue task > ------ ------------ > futex_wait_requeue_pi() > futex_wait_setup() > futex_queue(&q) > futex_requeue() > futex_proxy_trylock_atomic() > futex_requeue_pi_prepare() > Q_REQUEUE_PI_NONE->Q_REQUEUE_PI_IN_PROGRESS > > rt_mutex_start_proxy_lock() (ret = 0) > requeue_futex() > futex_do_wait() > futex_requeue_pi_complete() > Q_REQUEUE_PI_IN_PROGRESS -> Q_REQUEUE_PI_DONE > futex_requeue_pi_wakeup_sync() > rt_mutex_wait_proxy_lock() > rt_mutex_schedule() (on contention) > > In the Q_REQUEUE_PI_DONE case the waiter will acquire the pi_mutex. > Should the lock be contended, the waiter will invoke rt_mutex_schedule() > without invoking rt_mutex_.*_schedule() before/ after scheduling. > > Invoke rt_mutex_pre_schedule() and rt_mutex_post_schedule() directly around > rt_mutex_wait_proxy_lock(). Still doesn't explain why this is makes sense. Perhaps something like the below comment to demystify the code? > [bigeasy: Redid parts of the changelog, dropped the comment misleading] > > Fixes: d14f9e930b90 ("locking/rtmutex: Use rt_mutex specific scheduler helpers") > Suggested-by: Sebastian Andrzej Siewior > Signed-off-by: Yao Kai > Signed-off-by: Sebastian Andrzej Siewior > Reviewed-by: Sebastian Andrzej Siewior > --- > kernel/futex/requeue.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/kernel/futex/requeue.c b/kernel/futex/requeue.c > index 79823ad136830..d8c9e7d218695 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,10 @@ 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; > + /* * Since current is doing the requeue, it cannot also be * a waiter on the same futex. */ > + rt_mutex_pre_schedule(); > ret = rt_mutex_wait_proxy_lock(pi_mutex, to, &rt_waiter); > + rt_mutex_post_schedule(); > > /* > * See futex_unlock_pi()'s cleanup: comment. > -- > 2.55.0 >