From nobody Mon Jun 8 07:24:33 2026 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 9F3A33C2BB0; Thu, 4 Jun 2026 18:45:56 +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=1780598757; cv=none; b=EAfumupUOKlyxFXuZ9k+jMgAbDAaHVZNi1wZa1aNJ8hZg6LtnA5GCx68TdznOeWEdtZyrHUtj3CubPxSAbBIURrliEY6mpWqTdhP4HTLlWZZXfAWnhvr3aRAdjOY9ej0wYPt2Wlktv05eubsFkvvbo9whq6F1PR5IK6yS3E8YWo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780598757; c=relaxed/simple; bh=62aY519TXVuy1WQ9GlfmBQT/VO1z3dTh4s1TB90BHY4=; h=Date:From:To:Subject:Cc:In-Reply-To:References:MIME-Version: Message-ID:Content-Type; b=ZEwZUg21GLsimnLbFsCvm9jB4+hkBe838Ps2ZReW1g2mthNTeo9IJ+nnui7CMx0cYsQu9t0H8fHOKD1zeWU76+HNWmiLdCm/4RaZTuQCSxM1xE7a4ClGA6erOgEn6S1sW9Iq2X5qJee/r6hryvR46klliabRl8vLL5PdE0cjVtA= 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=YUF4fZ85; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=5tBwSY1q; 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="YUF4fZ85"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="5tBwSY1q" Date: Thu, 04 Jun 2026 18:45:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1780598755; h=from:from:sender:sender:reply-to: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=8r9jfj5TG1p49fFw23kwQyw7EZrW+QHHef5Jgh9LtOY=; b=YUF4fZ85dNDQjU9YQ3aWrtWkWtEBxXVs8pS2uLtHOecpY+OXXZpkNHRkR+51E8NQmNwrIC xay7FaVtZwUCntmjIWpK40cu7137swKfW6DNVW9YMC57g2dWtOdPSQrsKHh2U+fpWMo+ET djQ08lcUdhePoaXZG7rMRGbg8tXK/FOv7H7otSfZ+XoGqe1Qa4DKhqbU1Htjg2p5sKVziE nwIBmd7vsmIWgLhUpKbPiq1UKPbTnvcb4JJSuSfpA0W2pxwuKFKsvsfB6VltIArVWuCKIf b3p56OBRX9sSiWapFwWpXv7U0Q10JkNXlp0EhcA0cP61Y+9KauMrWaiCGKSkqQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1780598755; h=from:from:sender:sender:reply-to: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=8r9jfj5TG1p49fFw23kwQyw7EZrW+QHHef5Jgh9LtOY=; b=5tBwSY1q0RI13RDGg/9aZZSfp7v+3H5ofcVkkOZB4ehlcb0OMcY47cXJ5jsrGzEFKF6UMk OSFxBGnszqWx+OAQ== From: "tip-bot2 for John Stultz" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: sched/core] locking: mutex: Fix proxy-exec potentially deactivating tasks marked TASK_RUNNING Cc: Vineeth Pillai , John Stultz , "Peter Zijlstra (Intel)" , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20260430215103.2978955-3-jstultz@google.com> References: <20260430215103.2978955-3-jstultz@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-ID: <178059875389.710.15834781752494334176.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Precedence: bulk Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The following commit has been merged into the sched/core branch of tip: Commit-ID: bdaf235913e1f31453c6e0e109d797269f9f0a37 Gitweb: https://git.kernel.org/tip/bdaf235913e1f31453c6e0e109d797269= f9f0a37 Author: John Stultz AuthorDate: Thu, 30 Apr 2026 21:50:47=20 Committer: Peter Zijlstra CommitterDate: Tue, 02 Jun 2026 12:26:05 +02:00 locking: mutex: Fix proxy-exec potentially deactivating tasks marked TASK_R= UNNING Vineeth found came up with a test driver that could trip up workqueue stalls. After fixing one issue this test found, Vineeth reported the test was still failing. Greatly simplified, a task that tries to take a mutex already owned by another task that is sleeping, can hit a edge case in the mutex_lock_common() case. If the task fails to get the lock, calls into schedule, but gets a spurious wakeup, it will find that it is first waiter, and go into the mutex_optimistic_spin() logic. Though before calling mutex_optimistic_spin(), we clear task blocked_on state, since mutex_optimistic_spin() may call schedule() if need_resched() is set. After mutex_optimistic_spin() fails, we set blocked_on again, restart the main mutex loop, try to take the lock and call into schedule_preempt_disabled(). >From there, with proxy-execution, we'll see the task is blocked_on, follow the chain, see the owner is sleeping and dequeue the waiting task from the runqueue. This all sounds fine and reasonable. But what I had missed is that in mutex_optimistic_spin(), not only do we call schedule() but we set TASK_RUNNABLE right before doing so. This is ok for that invocation of schedule(). But when we come back we re-set the blocked_on we had just cleared, but we do not re-set the task state to TASK_INTERRUPTIBLE/UNINTERRUPTIBLE. This means we have a task that is blocked_on & TASK_RUNNABLE, so when the proxy execution code dequeues the task, we are in trouble since future wakeups will be shortcut by the ttwu_state_match() check. Thus, to avoid this, after mutex_optimistic_spin(), set the task state back when we set blocked_on. Many many thanks again to Vineeth for his very useful testing driver that uncovered this long hidden bug, that I hadn't tripped in all my testing! Very impressed with the problems he's uncovered! Reported-by: Vineeth Pillai Signed-off-by: John Stultz Signed-off-by: Peter Zijlstra (Intel) Tested-by: Vineeth Pillai Link: https://patch.msgid.link/20260430215103.2978955-3-jstultz@google.com --- kernel/locking/mutex.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c index 0953462..a93d4c6 100644 --- a/kernel/locking/mutex.c +++ b/kernel/locking/mutex.c @@ -763,6 +763,7 @@ __mutex_lock_common(struct mutex *lock, unsigned int st= ate, unsigned int subclas raw_spin_lock_irqsave(&lock->wait_lock, flags); raw_spin_lock(¤t->blocked_lock); __set_task_blocked_on(current, lock); + set_current_state(state); =20 if (opt_acquired) break;