linux-kernel - Re: [PATCH v16 5/7] 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANDhNCo--B2vNOkNjzKsO2F-UbNuR-mYVCyDJZk0OqTq+=U1_A@mail.gmail.com>
Date: Wed, 16 Apr 2025 15:55:27 -0700
From: John Stultz <jstultz@...gle.com>
To: Juri Lelli <juri.lelli@...hat.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>, 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>, K Prateek Nayak <kprateek.nayak@....com>, 
	Thomas Gleixner <tglx@...utronix.de>, Daniel Lezcano <daniel.lezcano@...aro.org>, 
	Suleiman Souhlal <suleiman@...gle.com>, kernel-team@...roid.com
Subject: Re: [PATCH v16 5/7] sched: Add an initial sketch of the
 find_proxy_task() function

On Mon, Apr 14, 2025 at 2:42 AM Juri Lelli <juri.lelli@...hat.com> wrote:
>
> Hi John,
>
> On 11/04/25 23:02, John Stultz wrote:
> > Add a find_proxy_task() function which doesn't do much.
> >
> > When we select a blocked task to run, we will just deactivate it
> > and pick again. The exception being if it has become unblocked
> > after find_proxy_task() was called.
> >
> > Greatly simplified from patch by:
> >   Peter Zijlstra (Intel) <peterz@...radead.org>
> >   Juri Lelli <juri.lelli@...hat.com>
> >   Valentin Schneider <valentin.schneider@....com>
> >   Connor O'Brien <connoro@...gle.com>
> >
> > Cc: Joel Fernandes <joelagnelf@...dia.com>
> > Cc: Qais Yousef <qyousef@...alina.io>
> > Cc: Ingo Molnar <mingo@...hat.com>
> > Cc: Peter Zijlstra <peterz@...radead.org>
> > Cc: Juri Lelli <juri.lelli@...hat.com>
> > Cc: Vincent Guittot <vincent.guittot@...aro.org>
> > Cc: Dietmar Eggemann <dietmar.eggemann@....com>
> > Cc: Valentin Schneider <vschneid@...hat.com>
> > Cc: Steven Rostedt <rostedt@...dmis.org>
> > Cc: Ben Segall <bsegall@...gle.com>
> > Cc: Zimuzo Ezeozue <zezeozue@...gle.com>
> > Cc: Mel Gorman <mgorman@...e.de>
> > Cc: Will Deacon <will@...nel.org>
> > Cc: Waiman Long <longman@...hat.com>
> > Cc: Boqun Feng <boqun.feng@...il.com>
> > Cc: "Paul E. McKenney" <paulmck@...nel.org>
> > Cc: Metin Kaya <Metin.Kaya@....com>
> > Cc: Xuewen Yan <xuewen.yan94@...il.com>
> > Cc: K Prateek Nayak <kprateek.nayak@....com>
> > Cc: Thomas Gleixner <tglx@...utronix.de>
> > Cc: Daniel Lezcano <daniel.lezcano@...aro.org>
> > Cc: Suleiman Souhlal <suleiman@...gle.com>
> > Cc: kernel-team@...roid.com
> > [jstultz: Split out from larger proxy patch and simplified
> >  for review and testing.]
> > Signed-off-by: John Stultz <jstultz@...gle.com>
> > ---
>
> ...
>
> > +static struct task_struct *
> > +find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)
> > +{
> > +     struct task_struct *p = donor;
> > +     struct mutex *mutex;
> > +
> > +     mutex = p->blocked_on;
> > +     /* Something changed in the chain, so pick again */
> > +     if (!mutex)
> > +             return NULL;
> > +     /*
> > +      * By taking mutex->wait_lock we hold off concurrent mutex_unlock()
> > +      * and ensure @owner sticks around.
> > +      */
> > +     guard(raw_spinlock)(&mutex->wait_lock);
> > +
> > +     /* Check again that p is blocked with blocked_lock held */
> > +     if (!task_is_blocked(p) || mutex != __get_task_blocked_on(p)) {
> > +             /*
> > +              * Something changed in the blocked_on chain and
> > +              * we don't know if only at this level. So, let's
> > +              * just bail out completely and let __schedule
> > +              * figure things out (pick_again loop).
> > +              */
> > +             return NULL; /* do pick_next_task again */
> > +     }
> > +     return proxy_deactivate(rq, donor);
>
> Nitpick. We might either want to use donor (and remove p) or use p
> everywhere in the function; think makes it more clear.

Ah, yes, in this step it, it would be more clear.  The two separate
values are important later when we walk the chain, since we use p to
iterate down the chain, but if we cannot find a proxy to run, we need
to deactivate the donor.

I'll rework this chunk to just use donor in this step.

thanks
-john