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 D5F67227EA4 for ; Fri, 17 Jul 2026 08:55:51 +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=1784278553; cv=none; b=NeBX9DSNSIIhQrTLKQHh7jLm9ehhxDRnwxp63Yko3GMGHT/A5OULEo8hcDK/Y+YzaZfYJ1E1DqN0GBaNNRTx8Jvr69g9s9prExwBtGOu59/hpRsXzjmdOmokQGnsGixldPnbWERIWhdLcm1uXHt50HmkB7EmrNSIs466z1UUy5o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784278553; c=relaxed/simple; bh=MXswq9ja26nwvmBh4kSfZ+zJRMrdfhs1QhqiQ0GEdp0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=OHxJOSWawJdW/NCWexSNB0JWWRsu9m+kDHXUAMowgAkHvqBT6Yh5sj9NdizjwctRzXbnMb6u4+Hm2weEZ48FMb+vJ+yZ47+cyUpGFeKfX3GuLhsvC79FMFOBi0jXDVBhzrsJbAtP1/0At1dTxpjADMAa+kml4W4F95wJmAa+vdk= 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=H/ALdUtK; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=s0Or8BYF; 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="H/ALdUtK"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="s0Or8BYF" Date: Fri, 17 Jul 2026 10:55:48 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1784278549; 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=/f7mYLOaJzvdhKQAUEPEHZUH3uG+Ty/V/wSZTExLRqM=; b=H/ALdUtKozTyiHSkj3CSrXim6G5sjGkW9R+mMxThNDZ5xd5Nbu3yB5GsPugwscUgog9PTI 5benou53JCawoQPqu0s9TFLTS5Ae4c4P6j2hY//2fupyy5CZUGR1l9VumUt0M5ll19AOTL kyUdGFdxrB7tVXlOj7vMTD+xAqQwmVnMCodcotXLmdIJltw7KXO8yJnNYMAl0ChGPq+Gv6 qXAYv5OiBPAAbTdewh8XAM/Ak1baw7b1MKE6huZjJefLqb6jOFJTNPQofndcHRh1N6O7K0 oYGL65D0/riVjD/pZ3KRm1is2ITcR/Dq69TV7MdpVIuW4bGwZj6OVjELo7z6Bg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1784278549; 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=/f7mYLOaJzvdhKQAUEPEHZUH3uG+Ty/V/wSZTExLRqM=; b=s0Or8BYFiUFSEv5w2nl+luV/x8srN+zxIIc0GnBPQAnt0K8x6ma0qDBTyF8QXMX9nHxV+n zNkuJs+Ydq4uYsBQ== 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: <20260717085548.slwReTBC@linutronix.de> References: <20260717084922.4153317-1-yaokai34@huawei.com> <20260717084922.4153317-2-yaokai34@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: <20260717084922.4153317-2-yaokai34@huawei.com> On 2026-07-17 16:49:21 [+0800], Yao Kai wrote: > A waiter requeued onto a PI futex can reach > rt_mutex_wait_proxy_lock() without rtmutex schedule preparation: > WARNING: CPU: 0 PID: 293 at kernel/sched/core.c:7606 > RIP: rt_mutex_schedule+0x43/0x50 > Call Trace: > rt_mutex_slowlock_block.constprop.0+0x5b/0x320 > rt_mutex_wait_proxy_lock+0x3e/0x80 > futex_wait_requeue_pi+0x3ba/0x590 > do_futex+0x171/0x1f0 > > rt_mutex_schedule() requires current->sched_rt_mutex to be set. Normally, > rt_mutex_pre_schedule() sets it and submits pending work before the waiter > is enqueued. With requeue PI, another task can enqueue the waiter after its > futex_q becomes visible: > > waiter requeue task > ------ ------------ > futex_wait_requeue_pi() > futex_wait_setup() > futex_queue(&q) > futex_requeue() > rt_mutex_start_proxy_lock() > enqueue rt_waiter > install pi_blocked_on > requeue_futex() > plist_del(&q->list) > futex_do_wait() > plist_node_empty(&q->list) > skip schedule() > plist_add(&q->list) > futex_requeue_pi_complete() > IN_PROGRESS -> DONE > futex_requeue_pi_wakeup_sync() // DONE > rt_mutex_wait_proxy_lock() > rt_mutex_schedule() > > futex_do_wait() mistakes the temporary removal for a wakeup and skips > schedule(). The waiter consequently enters rt_mutex_schedule() with > current->sched_rt_mutex clear. Its block plug remains unflushed, and > workqueue or io-wq users are not notified that the worker is going to > sleep. This has nothing to do with, does it? It is just usually the lock is acquired and it is not blocked on. Do you have testcase for this or is this just audit? > rt_mutex_pre_schedule() cannot be used directly. Calling it before q is > published would set current->sched_rt_mutex while futex_do_wait() can still > call regular schedule(). Calling it after DONE would flush the block plug > after current->pi_blocked_on is installed, which can recurse into rtmutex > waiter setup. > > Split the preparation instead. Flush the plug before futex_wait_setup() > publishes q. After futex_requeue_pi_wakeup_sync() returns DONE, enter the > rtmutex scheduling state and notify workqueue and io-wq users without > flushing the plug again. Split sched_submit_work() to support this ordering > and leave the scheduling state after the waiter has acquired the lock or > has been removed. > > Fixes: d14f9e930b90 ("locking/rtmutex: Use rt_mutex specific scheduler helpers") > Cc: stable@vger.kernel.org > Signed-off-by: Yao Kai 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.