linux-kernel - Re: [RESEND][PATCH v18 6/8] sched: Add an initial sketch of the find_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: <CANDhNCpxU=eLSwv2ViDm7-cGjXryRDXizWm=7rDYWE28c+BjjA@mail.gmail.com>
Date: Fri, 11 Jul 2025 20:58:38 -0700
From: John Stultz <jstultz@...gle.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: LKML <linux-kernel@...r.kernel.org>, K Prateek Nayak <kprateek.nayak@....com>, 
	Joel Fernandes <joelagnelf@...dia.com>, Qais Yousef <qyousef@...alina.io>, 
	Ingo Molnar <mingo@...hat.com>, 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: [RESEND][PATCH v18 6/8] sched: Add an initial sketch of the
 find_proxy_task() function

On Thu, Jul 10, 2025 at 5:43 PM John Stultz <jstultz@...gle.com> wrote:
> On Thu, Jul 10, 2025 at 3:02 AM Peter Zijlstra <peterz@...radead.org> wrote:
> > So far what it seems to do is when true, don't block. It still does the
> > signal thing -- but I can't tell if that is actually required or not.
...
> That said, I appreciate you raising the question, as looking at and
> thinking about it some more, I do see that we should be clearing the
> blocked_on state when we do set ourselves as runnable in that case,
> otherwise if we are blocked_on we might get stuck waiting for a wakeup
> (likely from the lock release).
>
> I'll fix that up here.

So just FYI, I actually talked myself out of that position last night
before finishing up and sending out v19. If we are blocked_on, we're
not going to get back to userland to handle the signal, we're just
going to wake up, spin through the mutex lock code and head back into
__schedule(), so clearing the blocked_on state isn't the right answer
there. Leaving the blocked_on task on the runqueue (even if we set it
TASK_RUNNABLE) until the blocked_on state is cleared should be fine.

I did some stress testing, and never actually saw a case where we had
signals pending and were blocked on, so it seems like a rare corner
case, and I feel leaving the existing longer-tested behavior is right.

thanks
-john