linux-kernel - Re: [PATCH v23 6/9] sched: Handle blocked-waiter migration (and return migration)

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: <CANDhNCrfaEpOyEVFM2GeaEDt_UrpZtgF1hOLVPkk2K+KgP4r0w@mail.gmail.com>
Date: Wed, 19 Nov 2025 18:00:15 -0800
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 6/9] sched: Handle blocked-waiter migration (and
 return migration)

On Wed, Nov 19, 2025 at 5:53 PM John Stultz <jstultz@...gle.com> wrote:
> On Sun, Nov 9, 2025 at 8:48 PM K Prateek Nayak <kprateek.nayak@....com> wrote:
> >
> > Hello John,
> >
> > On 11/8/2025 4:48 AM, John Stultz wrote:
> > >>> @@ -6689,26 +6834,41 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)
> > >>>                       return NULL;
> > >>>               }
> > >>>
> > >>> +             if (task_current(rq, p))
> > >>> +                     curr_in_chain = true;
> > >>> +
> > >>>               owner = __mutex_owner(mutex);
> > >>>               if (!owner) {
> > >>>                       /*
> > >>> -                      * If there is no owner, clear blocked_on
> > >>> -                      * and return p so it can run and try to
> > >>> -                      * acquire the lock
> > >>> +                      * If there is no owner, either clear blocked_on
> > >>> +                      * and return p (if it is current and safe to
> > >>> +                      * just run on this rq), or return-migrate the task.
> > >>>                        */
> > >>> -                     __clear_task_blocked_on(p, mutex);
> > >>> -                     return p;
> > >>> +                     if (task_current(rq, p)) {
> > >>> +                             __clear_task_blocked_on(p, NULL);
> > >>> +                             return p;
> > >>> +                     }
> > >>> +                     action = NEEDS_RETURN;
> > >>> +                     break;
> > >>>               }
> > >>>
> > >>>               if (!READ_ONCE(owner->on_rq) || owner->se.sched_delayed) {
> > >>
> > >> Should we handle task_on_rq_migrating() in the similar way?
> > >> Wait for the owner to finish migrating and look at the
> > >> task_cpu(owner) once it is reliable?
> > >
> > > Hrm. I'm not quite sure I understand your suggestion here. Could you
> > > expand a bit here? Are you thinking we should deactivate the donor
> > > when the owner is migrating? What would then return the donor to the
> > > runqueue? Just rescheduling idle so that we drop the rq lock
> > > momentarily should be sufficient to make sure the owner can finish
> > > migration.
> >
> > In find_proxy_task() we have:
> >
> >   if (!READ_ONCE(owner->on_rq) || owner->se.sched_delayed) {
> >     /* Returns rq->idle or NULL */
> >   }
> >
> >   /*
> >    * Owner can be task_on_rq_migrating() at this point
> >    * since it is in turn blocked on a lock owner on a
> >    * different CPU.
> >    */
> >
> >   owner_cpu = task_cpu(owner); /* Prev CPU */
> >   if (owner_cpu != this_cpu) {
> >     ...
> >     action = MIGRATE;
> >     break;
> >   }
> >
> >
> > So in the end we can migrate to the previous CPU of the owner
> > and the previous CPU has to do a chain migration again. I'm
> > probably overthinking about a very unlikely scenario here :)
>
> Ok, so you're suggesting maybe putting the
>     if (task_on_rq_migrating(owner))
> case ahead of the
>     if (owner_cpu != this_cpu)
> check?
>
> Let me give that a whirl and see how it does.

That said, thinking another second on it, I also realize once we
decide to proxy_migrate, there is always the chance the owner gets
migrated somewhere else. So we can check task_on_rq_migrating() but
then right after we check that it might be migrated, and we can't
really prevent this.  And in that case, doing the proxy-migration to
the wrong place will be ok, as that cpu will then bounce the tasks to
the owner's new cpu.

Hopefully this would be rare though. :)

thanks
-john