From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 7EF91332913 for ; Tue, 21 Jul 2026 07:23:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784618629; cv=none; b=cI8gbl6mk/0R7+PipOkJF9BQX/TJgxUNwhpGYq2FxO13XgE4Ys7H+Dl3A7HbVUWShreItDF5RiMHbMpU5mGA6ihkjDpTYSWkow34947Zp/+3qBF1GXCAq+FIeagQmVOLWCJDzWkod1DTctg2ibqk/TUBLWpnL/rh1q9RKgjhKbQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784618629; c=relaxed/simple; bh=8r/b1kOJYh+/bS0P8+vNKuvDsMavxhsA46L32KOH2FA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=u95JVTursdH8tqbXdsnRrUTqLTVjIqoEj4r6FjDLyUo0FhEj5Fs212m/bNxlSDX1jXLmLUgJVbJ3W08f4xgJD2YBjczP7ZhZvQJ96it9Kc2Ob7YsI0DZMLtoVS1rT/s6xpwld9ixLsbnigJ9n7SAYVL8siO0o8yRhk3FxHB9oYE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=2YmVn/6k; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=I4CNZXmH; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="2YmVn/6k"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="I4CNZXmH" Date: Tue, 21 Jul 2026 09:23:44 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1784618626; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5deRcWP5V3C2KOBfOpsPou2yC/5vYavzI0YRXjAPo+w=; b=2YmVn/6kQLj+NJWpORWA3cjLtIH6XMCMYZ8PAXeujJAf6MjgP+0dGG8Caj6Hd8ioCFKoVN IX/YP1j7RvS7t59yxVQhr3gjF3uxiEmRjIKYL3xIkyhVv3qDIEgHymdQIJDnILnMc5fFPE scf3wgzx7KwlV+/p5j/oCvrdyAJOqdFfB7wPWINIQO3awOKBWtwDHa9AxKXyRaetrHgqvz bJntmxUKOxUmXfdFqBIeo9+Jst8saj0ZwndBdxQGkZrQkEE1jo0rfyg2GCg5mdCPNx0iBW hyUxr5gBze+27kYNr/0JmOTSgZ3b7NNaERh/Db2b0No7Uogy4Gc2isa5m3IN9A== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1784618626; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5deRcWP5V3C2KOBfOpsPou2yC/5vYavzI0YRXjAPo+w=; b=I4CNZXmHygu6kA0bwI0n4HQVJNQqgP9vdwMebhqEaF4wEnzbnXEPP1HrmAdKSPHAMl1D4F dMzBxyWWFq9fUEDQ== From: Sebastian Andrzej Siewior To: Yao Kai Cc: linux-kernel@vger.kernel.org, tglx@kernel.org, mingo@redhat.com, peterz@infradead.org, dvhart@infradead.org, dave@stgolabs.net, andrealmeid@igalia.com, liuyongqiang13@huawei.com Subject: Re: [PATCH 1/2] futex/requeue: Fix rtmutex schedule preparation for requeue PI Message-ID: <20260721072344.IrNBbYYT@linutronix.de> References: <20260717084922.4153317-1-yaokai34@huawei.com> <20260717084922.4153317-2-yaokai34@huawei.com> <20260717085548.slwReTBC@linutronix.de> <89dce8bf-8aec-4b3a-a588-f3dab35e8977@huawei.com> <20260720145847.QW7LB9jE@linutronix.de> <52c53bc8-d22b-43e5-89c5-d2918940dc4d@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=utf-8 Content-Disposition: inline In-Reply-To: <52c53bc8-d22b-43e5-89c5-d2918940dc4d@huawei.com> On 2026-07-21 09:51:47 [+0800], Yao Kai wrote: > > > diff --git a/kernel/futex/requeue.c b/kernel/futex/requeue.c > > > index 79823ad13683..41ffc795d12c 100644 > > > --- a/kernel/futex/requeue.c > > > +++ b/kernel/futex/requeue.c > > > @@ -865,6 +865,7 @@ 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; > > > + rt_mutex_pre_schedule(); > > > ret = rt_mutex_wait_proxy_lock(pi_mutex, to, &rt_waiter); > > > /* > > > @@ -875,6 +876,7 @@ int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags, > > > futex_q_lockptr_lock(&q); > > > debug_rt_mutex_free_waiter(&rt_waiter); > > > + rt_mutex_post_schedule(); > > > > But there is futex_q_lockptr_lock() from what I see in the context. This > > one should trigger the warning if it is done as you suggest. > > > > I don't think it would trigger the warning. At this point rt_mutex_wait_proxy_lock() > or rt_mutex_cleanup_proxy_lock() has cleared current->pi_blocked_on. No, they don't. There is still this lockdep_assert() on current->sched_rt_mutex which ensures that you must always do rt_mutex_pre_schedule(), rt_mutex_schedule(), rt_mutex_post_schedule() in that order. And spin_lock() will do all three of the mutex is contended. Therefore you can leave rt_mutex_pre_schedule() across another possible rtmutex locking. > > > /* > > > * Fixup the pi_state owner and possibly acquire the lock if we > > > * haven't already. > > > > > > Thanks, > > > Yao Sebastian