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 AA2823EFD30 for ; Tue, 21 Jul 2026 01:51:51 +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=1784598715; cv=none; b=WgIWST5Z1Z/trfA7PxiJ5SWNB1OlxmNtN28hDdEZt9kpZ00LeMJu7xLMltvY8dLkP+iXkvJ4xToKGIrrGbiWQ1i0ggHA/QWGx+T4rNh/PZwdUnfu2lwJso+vedHXm3d5oEk1Tt6PzOKwASmuZLTqUsZmZC5e8YePz9tzj4jLVtA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784598715; c=relaxed/simple; bh=8NyiBn/iranNSHzentJYMRoEmsVZKbNVoRnW4eHLbnc=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=ZvDS0OtG0gXEIHGotYNwLvF8B1b5aE+RYdSj+SvDgEsFUItRWy/JFtVXhW4ccd5JT3FKDYolf9u2okZgMuqS9QdutwS80yoL7Taq0ZrfjorMm04HLSkBmJJ3+KL4KnQNLUZ3gr5t7NnBjnMX+cGKoVceeaN/SI2TKXLvJTT3ep4= 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=x5saPxj8; 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="x5saPxj8" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=HmMiYXB0DRoVL+YOkJijOmM6Ao7MB9acdYOluBAiWL8=; b=x5saPxj8SJvOo9H5xpS+WzGLMkRvfLx1XWSiDd+6IBz8OZb/6D1k10leiNojW9anyiMLjvr20 BGXpcZnM3l+xaSIh0CQM2kbhqBu+p+6kNYZKRBT0+xrM2Se/tOeI9TQuye/QY91gLwlYOagoU9K y0V1W9wMkFe2nVvkjJWNX+Y= Received: from mail.maildlp.com (unknown [172.19.163.104]) by canpmsgout05.his.huawei.com (SkyGuard) with ESMTPS id 4h40Vt1h0Wz12LDV; Tue, 21 Jul 2026 09:42:14 +0800 (CST) Received: from dggpemr500006.china.huawei.com (unknown [7.185.36.185]) by mail.maildlp.com (Postfix) with ESMTPS id CEF2B4057F; Tue, 21 Jul 2026 09:51:48 +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 09:51:48 +0800 Message-ID: <52c53bc8-d22b-43e5-89c5-d2918940dc4d@huawei.com> Date: Tue, 21 Jul 2026 09:51:47 +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> Content-Language: en-US From: Yao Kai In-Reply-To: <20260720145847.QW7LB9jE@linutronix.de> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems500001.china.huawei.com (7.221.188.70) To dggpemr500006.china.huawei.com (7.185.36.185) On 7/20/2026 10:58 PM, Sebastian Andrzej Siewior wrote: > 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: >> >> 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 = waiter >> >> 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 from >> this syscall. > > So the suggestion is okay then? > … > Yes. >>> what about the following? This might compile but lacks all kind of testing. >>> >>> 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, 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); >>> + rt_mutex_post_schedule(); >>> /* >>> * See futex_unlock_pi()'s cleanup: comment. >> >> This also fixes the warning in my test. I would keep rt_mutex_post_schedule() >> after the proxy waiter cleanup, as futex_lock_pi() does: > > But why? > Just to be consistent with the code in futex_lock_pi(): ret = rt_mutex_wait_proxy_lock(&q.pi_state->pi_mutex, to, &rt_waiter); cleanup: /* * If we failed to acquire the lock (deadlock/signal/timeout), we must * unwind the above, however we canont lock hb->lock because * rt_mutex already has a waiter enqueued and hb->lock can itself try * and enqueue an rt_waiter through rtlock. * * Doing the cleanup without holding hb->lock can cause inconsistent * state between hb and pi_state, but only in the direction of not * seeing a waiter that is leaving. * * See futex_unlock_pi(), it deals with this inconsistency. * * There be dragons here, since we must deal with the inconsistency on * the way out (here), it is impossible to detect/warn about the race * the other way around (missing an incoming waiter). * * What could possibly go wrong... */ if (ret && !rt_mutex_cleanup_proxy_lock(&q.pi_state->pi_mutex, &rt_waiter)) ret = 0; /* * Now that the rt_waiter has been dequeued, it is safe to use * spinlock/rtlock (which might enqueue its own rt_waiter) and fix up * the */ futex_q_lockptr_lock(&q); /* * Waiter is unqueued. */ rt_mutex_post_schedule(); >> 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. >> /* >> * Fixup the pi_state owner and possibly acquire the lock if we >> * haven't already. >> >> Thanks, >> Yao > > Sebastian