linux-kernel - Re: [PATCH v23 5/9] sched: Add logic to zap balance callbacks if we pick again

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: <CANDhNCo4bLw1sYqVVXUji4STdj68xV6OTu2tVosqUXmkN0r4ow@mail.gmail.com>
Date: Thu, 30 Oct 2025 20:15:31 -0700
From: John Stultz <jstultz@...gle.com>
To: K Prateek Nayak <kprateek.nayak@....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 5/9] sched: Add logic to zap balance callbacks if we
 pick again

On Thu, Oct 30, 2025 at 1:08 AM K Prateek Nayak <kprateek.nayak@....com> wrote:
> On 10/30/2025 5:48 AM, John Stultz wrote:
> > +#ifdef CONFIG_SCHED_PROXY_EXEC
> > +/*
> > + * Only called from __schedule context
> > + *
> > + * There are some cases where we are going to re-do the action
> > + * that added the balance callbacks. We may not be in a state
> > + * where we can run them, so just zap them so they can be
> > + * properly re-added on the next time around. This is similar
> > + * handling to running the callbacks, except we just don't call
> > + * them.
> > + */
> > +static void zap_balance_callbacks(struct rq *rq)
> > +{
> > +     struct balance_callback *next, *head;
> > +     bool found = false;
> > +
> > +     lockdep_assert_rq_held(rq);
> > +
> > +     head = rq->balance_callback;
> > +     while (head) {
> > +             if (head == &balance_push_callback)
> > +                     found = true;
> > +             next = head->next;
> > +             head->next = NULL;
> > +             head = next;
> > +     }
> > +     rq->balance_callback = found ? &balance_push_callback : NULL;
> > +}
>
> There is nothing proxy-exec specific in this function. Do we need to
> keep it behind CONFIG_SCHED_PROXY_EXEC?
>
> I believe compiler will optimize out the dead code and having
> zap_balance_callbacks() unconditionally shouldn't have make any
> difference to the size of generated binary for
> !CONFIG_SCHED_PROXY_EXEC case.

Good point. I'll drop that.


> Apart from that nit. feel free to include:
>
> Reviewed-by: K Prateek Nayak <kprateek.nayak@....com>

Thank you!

> > @@ -6901,10 +6933,15 @@ static void __sched notrace __schedule(int sched_mode)
> >       rq_set_donor(rq, next);
> >       if (unlikely(task_is_blocked(next))) {
> >               next = find_proxy_task(rq, next, &rf);
> > -             if (!next)
> > +             if (!next) {
> > +                     /* zap the balance_callbacks before picking again */
> > +                     zap_balance_callbacks(rq);
> >                       goto pick_again;
> > -             if (next == rq->idle)
> > +             }
> > +             if (next == rq->idle) {
> > +                     zap_balance_callbacks(rq);
>
> Also I would have preferred to have that zap_balance_callbacks() in
> proxy_resched_idle() but this is okay too.

So my initial hesitation here is just we call proxy_resched_idle() in
other situations where we might return NULL from find_proxy_task() as
well. So this avoids calling zap_balance_callbacks() twice.

But thinking some more, later in the full series we often call
proxy_resched_idle() in those paths where we are briefly dropping the
rq lock and we often call zap_balance_callbacks as well there. I'll
take a closer look at the full patch series and see if that doesn't
make sense to consolidate then.  Not 100% sure it will work out, but
worth looking into.

Thanks for the suggestion!
-john