linux-kernel - Re: [PATCH v23 7/9] sched: Have try_to_wake_up() handle return-migration for PROXY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <df244079-b1ab-492e-93c4-503b60c16c7d@amd.com>
Date: Thu, 20 Nov 2025 08:45:54 +0530
From: K Prateek Nayak <kprateek.nayak@....com>
To: John Stultz <jstultz@...gle.com>
CC: LKML <linux-kernel@...r.kernel.org>, Joel Fernandes
	<joelagnelf@...dia.com>, Qais Yousef <qyousef@...alina.io>, Ingo Molnar
	<mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>, Juri Lelli
	<juri.lelli@...hat.com>, Vincent Guittot <vincent.guittot@...aro.org>,
	Dietmar Eggemann <dietmar.eggemann@....com>, Valentin Schneider
	<vschneid@...hat.com>, Steven Rostedt <rostedt@...dmis.org>, Ben Segall
	<bsegall@...gle.com>, Zimuzo Ezeozue <zezeozue@...gle.com>, Mel Gorman
	<mgorman@...e.de>, Will Deacon <will@...nel.org>, Waiman Long
	<longman@...hat.com>, Boqun Feng <boqun.feng@...il.com>, "Paul E. McKenney"
	<paulmck@...nel.org>, Metin Kaya <Metin.Kaya@....com>, Xuewen Yan
	<xuewen.yan94@...il.com>, Thomas Gleixner <tglx@...utronix.de>, "Daniel
 Lezcano" <daniel.lezcano@...aro.org>, Suleiman Souhlal <suleiman@...gle.com>,
	kuyo chang <kuyo.chang@...iatek.com>, hupu <hupu.gm@...il.com>,
	<kernel-team@...roid.com>
Subject: Re: [PATCH v23 7/9] sched: Have try_to_wake_up() handle
 return-migration for PROXY_WAKING case

Hello John,

On 11/20/2025 6:35 AM, John Stultz wrote:
>> Sounds like block_task() would be better than deactivate_task() above
>> in that case. Anything that is waiting on the task's state change takes
>> the pi_lock afaik and the wakeup is always done with pi_lock held so
>> blocking the task shouldn't cause any problems based on my reading.
> 
> So earlier I did try using block_task() but it always seemed to run
> into crashes, which I assumed was because other cpus were picking the
> task up as it wasn't on_rq (any references to a task after
> block_task() in other situations often runs into this trouble).
> 
> But your point about the pi_lock being held is a good one, so I will
> tinker and think a bit more on this.

So if you hadn't used DEQUEUE_SPECIAL previously with block_task(),
there is a case where:

> @@ -3784,6 +3834,8 @@ static int ttwu_runnable(struct task_struct *p, int wake_flags)
>  		update_rq_clock(rq);
>  		if (p->se.sched_delayed)
>  			enqueue_task(rq, p, ENQUEUE_NOCLOCK | ENQUEUE_DELAYED);
> +		if (proxy_needs_return(rq, p))
> +			goto out;

Task turns delayed here but the delayed condition is handled
before proxy_needs_return(). Perhaps you can try reordering
them?

Since we avoid calling block_task() on blocked donors, I
don't think they can be delayed until we actually call
block_task().

I might be missing other subtleties but this is one case
I could think of.

>  		if (!task_on_cpu(rq, p)) {
>  			/*
>  			 * When on_rq && !on_cpu the task is preempted, see if

-- 
Thanks and Regards,
Prateek