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 2D09D446067 for ; Tue, 21 Jul 2026 09:45:23 +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=1784627126; cv=none; b=ZlCPv8Hc2eyjoFAgmMf/Y/VYhASO+y98u8pub4gUZN9ohRFuSGKjRe1QLCgmmtOLNN3T/duNJJg3GqhxOd2u3PsXT2ez/t5VfExoi/vOgUY50rqU+1He2cQgIDfTQU9IfiC6N4ErdPZY1nHda3ay5SZzoX8CjXzfOwi8r+nxWkI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784627126; c=relaxed/simple; bh=u8OiJhCZt6YdvV2RIVR0fFaHv2cdTMD+awBNRCDIKIk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jkwiOENFIwV5R7oyeSvNbgPvU1cjn95DIgH1+FADL0GPL9jO9MYkCPWu7FySSlwWt1GahaYIDuDak6DhCUtmRzXWUSESVofw3z4c0vhmWhC3QOGZgCCq/Q2GJK2oczvzyCejRZmdlMTrbLJ/hUBhIzCVAuZwoAgNvaOv/Cn+gaA= 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=WxrhEy1+; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=wnIHBgWN; 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="WxrhEy1+"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="wnIHBgWN" Date: Tue, 21 Jul 2026 11:45:20 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1784627121; 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=iWWXjIKLnCffRBI9zT14HNkkojf/QbpzPIFSGPeszmw=; b=WxrhEy1+qVnhYlKLRyJu+xcmh5/FMr/vdlRRHb+6/t1LYZGET792/Bgc54Qija0vW3uwnQ VU7Qz2TUPRj6VXXNm7lktRt6LntEFLTeVzJeJz3WtqELrs0inz/79txe9eM4Bn7G4c7aen z12Q9JVwNkxD49QTyPHL+PdMDQ8FAmFdM6WWnWYK3rVJBSa+x8cjrMlmdzI9AiyH3+Yrvg wpNiCuSa7eBVv3zmBxa4vVQAA9PGGW61cBT7a2RgLJnVmmaEr35nofv47FGPeJ/7bwdh5Z Nns5R4FVGbrYDOHMzfHhjl4U3hbg8QSiNy+6ngPca+JLABpcaKsSq6J4RKyrgg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1784627121; 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=iWWXjIKLnCffRBI9zT14HNkkojf/QbpzPIFSGPeszmw=; b=wnIHBgWN1hyk7i0YHxyaBmlK5mYpaiG7Gi6E/uRkXxCCxP7LRTfxTdqSdzzJULOwKDrDTX B2oTLYxPveHlB2Bg== 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: <20260721094520.Taal48-R@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> <20260721072344.IrNBbYYT@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=utf-8 Content-Disposition: inline In-Reply-To: On 2026-07-21 17:02:11 [+0800], Yao Kai wrote: > > Unless I am missing something, spin_lock() does not use the regular > rt_mutex pre/schedule/post sequence on PREEMPT_RT. Its contended path > uses schedule_rtlock(): > > spin_lock() > rt_spin_lock() > _rt_spin_lock() > rtlock_lock() > lockdep_assert(!current->pi_blocked_on); > rtlock_slowlock() > rtlock_slowlock_locked() > schedule_rtlock() > > At this point current->pi_blocked_on has already been cleared ,so the > assertion in rtlock_lock() is also satisfied. Ach right. We don't do this for spinlock_t but for everything non-spinning on !RT. So it should be fine. > That said, I think it is also acceptable to place > rt_mutex_post_schedule() immediately after rt_mutex_wait_proxy_lock(). We delay it in futex_lock_pi() for other reasons. You could push down after debug_rt_mutex_free_waiter() but I don't see the reason for it. Having only where it is needed with a short comment why it is needed, would be appreciated :) > Yao Sebastian