Re: [PATCH RT 15/25] sched: migrate_enable: Use select_fallback_rq()

From: Scott Wood
Date: Mon Feb 24 2020 - 17:16:05 EST


On Mon, 2020-02-24 at 17:05 +0100, Sebastian Andrzej Siewior wrote:
> On 2020-02-24 09:31:06 [-0600], Tom Zanussi wrote:
> > On Mon, 2020-02-24 at 10:43 +0100, Sebastian Andrzej Siewior wrote:
> > > On 2020-02-21 15:24:43 [-0600], zanussi@xxxxxxxxxx wrote:
> > > > From: Scott Wood <swood@xxxxxxxxxx>
> > > >
> > > > v4.14.170-rt75-rc1 stable review patch.
> > > > If anyone has any objections, please let me know.
> > >
> > > This creates bug which is stuffed later via
> > > sched: migrate_enable: Busy loop until the migration request is
> > > completed
> > >
> > > So if apply this, please take the bug fix, too. This is Stevens queue
> > > for reference:
> > > > [PATCH RT 22/30] sched: migrate_enable: Use select_fallback_rq()
> > >
> > > ^^ bug introduced
> > >
> >
> > Hmm, it seemed from the comment on the 4.19 series that it was '24/32
> > sched: migrate_enable: Use stop_one_cpu_nowait()' that required 'sched:
> > migrate_enable: Busy loop until the migration request is
> > completed' as a bug fix.
> >
> >
> > https://lore.kernel.org/linux-rt-users/20200122083130.kuu3yppckhyjrr4u@xxxxxxxxxxxxx/#t
> >
> > I didn't take the stop_one_cpu_nowait() one, so didn't take the busy
> > loop one either.
>
> Ach, it was the different WARN_ON() then. So this might not introduce
> any bug then. *Might*.
> Steven backported the whole pile and you took just this one patch. The
> whole set was tested in devel and uncovered a problem which was fixed
> later. Taking only a part *may* expose other problems it *may* be fine.

Taking up to this patch should be OK (well, you still have the
current->state clobbering, but it shouldn't introduce any new known bugs).
The busy loop patch itself has a followup fix though (in theory the busy
loop could deadlock): 2dcd94b443c5dcbc ("sched: migrate_enable: Use per-cpu
cpu_stop_work") which should be considered for v4.19 rt stable which has the
busy loop patch.

-Scott