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
