From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout05.his.huawei.com (canpmsgout05.his.huawei.com [113.46.200.220]) (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 14CDC3C1F2B for ; Tue, 21 Jul 2026 09:02:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.220 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784624540; cv=none; b=XHivgmfuOpGpEvImEXKAP+S/hgoAoD4/dOU09Cwcm2+eflrAAwJHsu77sMVbrMyaI88G3uqVKJQORx4incGppC0aeL5ZOwc5FZ2MQMaXMvY9rlMIckL0FJf5c1zruU9VcovOdntTF5nbfupgpH2zqAkJQPs0HnUzd2l3O4psD10= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784624540; c=relaxed/simple; bh=yrDs4yZBVwTZhlsdRAmd3v7QjQsglhramqdjDqXolhQ=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=M9hQlfi71oZBWBoA3Mxldk9snjzeFiqbGuA93zbAP4zElTTAmuuJX4Z9kFEv6QiOzvyOdO7kcoE4Q2I/1JmdoxPNA+APd9VstYLUR565+EJfPmQJNC3s0Vl4a6WQB6g9rlpAtUONYAuGusduIEwcXHTUkQXj6Cl+lQJyCE297Xs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=Yc3AToPd; arc=none smtp.client-ip=113.46.200.220 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="Yc3AToPd" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=OK3d3bysBV+fSU/c3kQN2CoI6ETT1iI28PV/DBa2nzo=; b=Yc3AToPdmC844T8tV/+3UvO5Vbde4ClvQLezJrHNYO+Ha/Z4za6OQGTUZk6P5mNXvndPnTNXm okdXIXw9dJwFTHAtO41ni2PqxFKrBKQ2MDStyuzQtJILqYJYit2GnQPMTMsFef64PP7Y2yxa00l ptb/NYwqvwT7OnraXF6p0tA= Received: from mail.maildlp.com (unknown [172.19.162.140]) by canpmsgout05.his.huawei.com (SkyGuard) with ESMTPS id 4h4B3V0bNbz12LG0; Tue, 21 Jul 2026 16:52:38 +0800 (CST) Received: from dggpemr500006.china.huawei.com (unknown [7.185.36.185]) by mail.maildlp.com (Postfix) with ESMTPS id 7EEBE202E6; Tue, 21 Jul 2026 17:02:12 +0800 (CST) Received: from [100.103.109.15] (100.103.109.15) by dggpemr500006.china.huawei.com (7.185.36.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 21 Jul 2026 17:02:11 +0800 Message-ID: Date: Tue, 21 Jul 2026 17:02:11 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] futex/requeue: Fix rtmutex schedule preparation for requeue PI To: Sebastian Andrzej Siewior CC: , , , , , , , 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> Content-Language: en-US From: Yao Kai In-Reply-To: <20260721072344.IrNBbYYT@linutronix.de> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems500001.china.huawei.com (7.221.188.70) To dggpemr500006.china.huawei.com (7.185.36.185) On 7/21/2026 3:23 PM, Sebastian Andrzej Siewior wrote: > 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. > 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. That said, I think it is also acceptable to place rt_mutex_post_schedule() immediately after rt_mutex_wait_proxy_lock(). >>>> /* >>>> * Fixup the pi_state owner and possibly acquire the lock if we >>>> * haven't already. >>>> >>>> Thanks, >>>> Yao > > Sebastian Yao