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 A43103C5546 for ; Mon, 20 Jul 2026 14:58:50 +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=1784559532; cv=none; b=BHw2uzhzIXx06Tav9TjKqbKmqvbu33smV0AEIidgh8ay4E7KfVcRKZF618n6OWzXHmo8m3ndmJf3DLKdR3HPTImpIsEeBYE/IIvhZJbALoS3bABMgiageerfQLgVqW7yUXc+zdlaGqRLTiIPQDnLU7+uVKyOQkHOiYMYIEietd0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784559532; c=relaxed/simple; bh=t0UL+HZXVO9oZklN6QwbGB/mfw5jtSsrH9neTSKHN3I=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=uDo0dmgpdZ8ujt6vgPxAnr3kpkBIGR/ocEG4Q73m8EZvnlZUvb4Pl3qXUKsgzaOWRbW8a45tGi8E1TyzLKn7LETSDSxmqGcDtkYtaHtjrINhTAjt/asGW/DISDKz4A0FAKb+FUzPoIy8UA8/FdyN7UPN1Jsgh/Wlvum8kmkIxzM= 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=hZguM+F1; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=HVKl59wT; 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="hZguM+F1"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="HVKl59wT" Date: Mon, 20 Jul 2026 16:58:47 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1784559528; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=imXskjhtR2Plr2uye7HLpb/0Mh0FeJPMrRZ4JOF7CRw=; b=hZguM+F1xFwA7nEOb7rzqqbT3GE02XTUGmPvOBRmdPWHnFQXkeFEPb3PKxTblRO/wn4jiF 5ErAMdok++aFYRYA9Ib7qYbIhaG36KVYsOFUzw9kij9uuzOewLSGNNQxMOynkqHlZjmLL1 8XI0fRikF8j35IHO0LPNfaqL7EHFtKgVMELhH4WAfwwAS6eRp2KeXGawiNWQpfEcxwKmzK vmuKhd78kuPCv5P99QXCgNtSDZnyfdKWQ78dlbykVR7vUwjk+zYP6Bxz3J4ihU7wBzMzUI Te44t5UXpYhYxiQfRsmRKMiYTDG+oMiwSW7PWwqiIXj4QcIHYg9c5M4M2jgm/A== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1784559528; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=imXskjhtR2Plr2uye7HLpb/0Mh0FeJPMrRZ4JOF7CRw=; b=HVKl59wT/tJpqi3ixJgZrAPmEjOmhhQ7csnTw9CoX2EARMJMwU02uAD6ZxwAPTXHmshZxG eCfM0Cc40MiX5XDg== 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: <20260720145847.QW7LB9jE@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> 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 Content-Transfer-Encoding: quoted-printable In-Reply-To: <89dce8bf-8aec-4b3a-a588-f3dab35e8977@huawei.com> On 2026-07-20 10:40:03 [+0800], Yao Kai wrote: > I have a test but it only triggers the warning. The concern about calling > rt_mutex_pre_schedule() after the proxy waiter has been enqueued came from > audit. A generic PREEMPT_RT path could be: >=20 > rt_mutex_pre_schedule() > sched_submit_work() > blk_flush_plug() > __blk_flush_plug() > flush_plug_callbacks() > drbd_unplug() > spin_lock_irq() > rtlock_slowlock() > task_blocks_on_rt_mutex() > current->pi_blocked_on =3D waiter >=20 > However, I could not find a path for FUTEX_WAIT_REQUEUE_PI to enter with a > live current->plug or worker flags, so this recursion is not reachable fr= om > this syscall. So the suggestion is okay then? =E2=80=A6 > > what about the following? This might compile but lacks all kind of test= ing. > >=20 > > diff --git a/kernel/futex/requeue.c b/kernel/futex/requeue.c > > index 79823ad136830..42a04e6e774c4 100644 > > --- a/kernel/futex/requeue.c > > +++ b/kernel/futex/requeue.c > > @@ -865,7 +865,9 @@ int futex_wait_requeue_pi(u32 __user *uaddr, unsign= ed int flags, > > case Q_REQUEUE_PI_DONE: > > /* Requeue completed. Current is 'pi_blocked_on' the rtmutex */ > > pi_mutex =3D &q.pi_state->pi_mutex; > > + rt_mutex_pre_schedule(); > > ret =3D rt_mutex_wait_proxy_lock(pi_mutex, to, &rt_waiter); > > + rt_mutex_post_schedule(); > > /* > > * See futex_unlock_pi()'s cleanup: comment. >=20 > This also fixes the warning in my test. I would keep rt_mutex_post_schedu= le() > after the proxy waiter cleanup, as futex_lock_pi() does: But why? > 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 rtmu= tex */ > pi_mutex =3D &q.pi_state->pi_mutex; > + rt_mutex_pre_schedule(); > ret =3D 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. > /* > * Fixup the pi_state owner and possibly acquire the lock= if we > * haven't already. >=20 > Thanks, > Yao Sebastian