From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 57982258EFC for ; Fri, 21 Nov 2025 11:54:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763726095; cv=none; b=CVSpV7tVFozgk9c4BTwqcX/DoCEh0KOHZZqMemoUI3YRKuv9YESf5Ug2epd8wRI8T3iTPUQwnNZHbIlKJm1lkkZnIUrxjMBTmsd2QUor9idb5ux5pggsyEYOZ5Lwto9FXMGuorFXsODa8iZKn4laCkW0HAATjJJHwvlyizKhLxk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763726095; c=relaxed/simple; bh=AWjUjii/3pioTHbXgfJHZRlbVnbDqf1Xw07wio29YIU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Pqbj1+cOW4e0OlhRWr0XE1JBFWZh/aU0BSAJLLxZ2AbzgeUTwsFtnBv0/gbhNCRDpzG98jBXrbFSH91tDr5RIeDZQyHl+iBmk6WbJ4XZFfHHsSYQ1yjxLpc+9+a5OvgSHTIGa1Y9wL0BXKQijUaktLfNF66s7cABhJ2Cn3uGgxo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org; spf=pass smtp.mailfrom=cmpxchg.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b=qNaPqbM7; arc=none smtp.client-ip=209.85.128.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b="qNaPqbM7" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4775ae5684fso9161455e9.1 for ; Fri, 21 Nov 2025 03:54:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1763726088; x=1764330888; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=9eSI1SkRIfzk1gBGHnzkuwQzBB0cems0pKpNJtjdfs8=; b=qNaPqbM7fT2cOBPIHS3/V7O//uaUD/eaDRE1cGy4cMLy+skk103482pcu2e8+oHj0A VqBJ9OFV9j2WViAVOoqZJU+mR8mDZmIJ+lXN8TyczazHKICmqnj//G0zThYjSnSxaezP 8ln4LBOQMXMrlIeLbA8AgX8eHjsuM7FNabvVR49E0rR35JKkNaCvZFBwI3Cic0/jEtGN WxOQAOb+t3jCM3c4P14lJv2BEdnyEK9T5hQh5JWfRsaCQJ2FeSlqQBRBCmwyX3AeY8Wl yLVQPTctr7VBIB5I4u2GWG5N6BgR594La+fRkWu078DSd+2ynYrytQr1yubh6AQB9Kmr 7+1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763726088; x=1764330888; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9eSI1SkRIfzk1gBGHnzkuwQzBB0cems0pKpNJtjdfs8=; b=P3G/1AQmwk1O8uY2CACDVAh4HR1t2v8od1ByqAe44HvUYLeKJ0ghW/iIUcip4cybJG 8sdAtx2GTiOf7x1NGY6T1wyG9qzIhud+ivC9vgV6bPZG9eUhYJsnt9MTD3FEecw4viaG oHfi+ervM1lesS+xEUaxGExTVB1WuTF+LmqnqFkw0oaUvQBRsI3nQl9xqlA5nuB65iou yxQTzmwmdBrcgC0KoSS1vDsdMzeFkYPyNWEhb0O/sRtYofiC8QSuf4+U4ZpE+6KvyE6m nnSBx6ZOBk89bbrzuqtN6WZpfukd95vQslFWJTA+B+MIXHO+1vL3fF6Gi8J1jaW0w3+0 ucUQ== X-Gm-Message-State: AOJu0YynaWmwDGUHRS3BXpcELZbIK74OunZxRVVkYD7PAQGVLqbhpmW9 gNFdK5nJkQ9RbVZdtJkZWGQXM2gcV2HWZGS2le6F21yOd9sJL9ng6Ji1g+7hVRUJRVY= X-Gm-Gg: ASbGncshGRlXVn56Grsn5wQiMH0hAWDkxyWM9Luk3tlpGjgY2zkLvHf4QWP/4nHGg7I NvhHQJXa6PNTr5MMCWPeDneUlwM6LFse/AxRo0YYv8NAzaICwx06hFkuauYWVjG+7DgwEUpp2xN BnSKvs30UD1L+cshEhy79ZPj/JEcPddrcnbLFstQ0Aox/Vit+jo0DJYqbAM0B76RuYTPpGHTM+f TzqzUSMV8ILbFXHfBev6yWAof3+LS0d55TSHHYVbK7zIlOuCyMkV5Pq+FUsklbaCBUqfextOlQx XgAN68GtqDHKXrHH7rF8G90ok6AwQDeLSZSY65SfdvwYvdDGmTib8pPWolH+NvDlwojj2CMPJi/ 0cM8sPPveIpO+vNCFhDpX37eQgwmj78fuVne4DMCgZQpXgYkHTNVg2sWNxv+zUJUTFu27 X-Google-Smtp-Source: AGHT+IFCuSfBS+TTmnt8OmFD6pep6JtRbEj7V4nLmCkk4LkYveobHma8ZbKdrQRz2g2yOcaU5MrX5A== X-Received: by 2002:a05:600c:19ce:b0:46e:48fd:a1a9 with SMTP id 5b1f17b1804b1-477c115dfaamr16851485e9.33.1763726088007; Fri, 21 Nov 2025 03:54:48 -0800 (PST) Received: from localhost ([2620:10d:c092:600::1:610c]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-42cb7f2e432sm10241334f8f.9.2025.11.21.03.54.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Nov 2025 03:54:47 -0800 (PST) Date: Fri, 21 Nov 2025 06:54:43 -0500 From: Johannes Weiner To: John Stultz Cc: LKML , K Prateek Nayak , Joel Fernandes , Qais Yousef , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Valentin Schneider , Suren Baghdasaryan , Steven Rostedt , Ben Segall , Zimuzo Ezeozue , Mel Gorman , Will Deacon , Waiman Long , Boqun Feng , "Paul E. McKenney" , Metin Kaya , Xuewen Yan , Thomas Gleixner , Daniel Lezcano , Suleiman Souhlal , kuyo chang , hupu , kernel-team@android.com Subject: Re: [PATCH] sched: Fix psi_dequeue for Proxy Execution Message-ID: <20251121115443.GB71307@cmpxchg.org> References: <20251118055242.4030849-1-jstultz@google.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=us-ascii Content-Disposition: inline In-Reply-To: <20251118055242.4030849-1-jstultz@google.com> On Tue, Nov 18, 2025 at 05:52:23AM +0000, John Stultz wrote: > Currently, if the sleep flag is set, psi_dequeue() doesn't > change any of the psi_flags. > > This is because psi_switch_task() will clear TSK_ONCPU as well > as other potential flags (TSK_RUNNING), and the assumption is > that a voluntary sleep always consists of a task being dequeued > followed shortly there after with a psi_sched_switch() call. > > Proxy Execution changes this expectation, as mutex-blocked tasks > that would normally sleep stay on the runqueue. But in the case > where the mutex-owning task goes to sleep, or the owner is on a > remote cpu, we will then deactivate the blocked task shortly > after. > > In that situation, the mutex-blocked task will have had its > TSK_ONCPU cleared when it was switched off the cpu, but it will > stay TSK_RUNNING. Then if we later dequeue it (as currently done > if we hit a case find_proxy_task() can't yet handle, such as the > case of the owner being on another rq or a sleeping owner) > psi_dequeue() won't change any state (leaving it TSK_RUNNING), > as it incorrectly expects a psi_task_switch() call to > immediately follow. > > Later on when the task get woken/re-enqueued, and psi_flags are > set for TSK_RUNNING, we hit an error as the task is already > TSK_RUNNING: > psi: inconsistent task state! task=188:kworker/28:0 cpu=28 psi_flags=4 clear=0 set=4 > > To resolve this, extend the logic in psi_dequeue() so that > if the sleep flag is set, we also check if psi_flags have > TSK_ONCPU set (meaning the psi_task_switch is imminent) before > we do the shortcut return. > > If TSK_ONCPU is not set, that means we've already switched away, > and this psi_dequeue call needs to clear the flags. > > Fixes: be41bde4c3a8 ("sched: Add an initial sketch of the find_proxy_task() function") > Reported-by: K Prateek Nayak > Closes: https://lore.kernel.org/lkml/20251117185550.365156-1-kprateek.nayak@amd.com/ > Signed-off-by: John Stultz > Tested-by: K Prateek Nayak > --- > v13: > * Reworked for collision > v15: > * Fixed commit message typo noticed by Todd Kjos > v24: > * Reworded commit message in response to K Prateek pointing > out this issue can affect us earlier in the full proxy > series then I had anticipated. > > Cc: Joel Fernandes > Cc: Qais Yousef > Cc: Ingo Molnar > Cc: Peter Zijlstra > Cc: Juri Lelli > Cc: Vincent Guittot > Cc: Dietmar Eggemann > Cc: Valentin Schneider > Cc: Johannes Weiner > Cc: Suren Baghdasaryan > Cc: Steven Rostedt > Cc: Ben Segall > Cc: Zimuzo Ezeozue > Cc: Mel Gorman > Cc: Will Deacon > Cc: Waiman Long > Cc: Boqun Feng > Cc: "Paul E. McKenney" > Cc: Metin Kaya > Cc: Xuewen Yan > Cc: K Prateek Nayak > Cc: Thomas Gleixner > Cc: Daniel Lezcano > Cc: Suleiman Souhlal > Cc: kuyo chang > Cc: hupu > Cc: kernel-team@android.com > --- > kernel/sched/stats.h | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/kernel/sched/stats.h b/kernel/sched/stats.h > index 26f3fd4d34cea..a38459813b537 100644 > --- a/kernel/sched/stats.h > +++ b/kernel/sched/stats.h > @@ -180,8 +180,12 @@ static inline void psi_dequeue(struct task_struct *p, int flags) > * avoid walking all ancestors twice, psi_task_switch() handles > * TSK_RUNNING and TSK_IOWAIT for us when it moves TSK_ONCPU. > * Do nothing here. Newline here for new paragraph? > + * In the SCHED_PROXY_EXECUTION case we may do sleeping > + * dequeues that are not followed by a task switch, so check > + * TSK_ONCPU is set to ensure the task switch is imminent. > + * Otherwise clear the flags as usual. > */ > - if (flags & DEQUEUE_SLEEP) > + if ((flags & DEQUEUE_SLEEP) && (p->psi_flags & TSK_ONCPU)) > return; Otherwise, looks good to me. Thanks for the detailed explanation in the changelog! Acked-by: Johannes Weiner