On Tue, 2020-04-28 at 09:03 +0200, Rasmus Villemoes wrote: > On 23/01/2020 21.39, Steven Rostedt wrote: > > 4.19.94-rt39-rc2 stable review patch. > > If anyone has any objections, please let me know. > > > > ------------------ > > > > From: Julien Grall <[email protected]> > > > > [ Upstream commit cef1b87f98823af923a386f3f69149acb212d4a1 ] > > > > As tglx puts it: > > > If base == migration_base then there is no point to lock > > > soft_expiry_lock > > > simply because the timer is not executing the callback in soft > > > irq context > > > and the whole lock/unlock dance can be avoided. > > Hold on a second. This patch (hrtimer: Prevent using > hrtimer_grab_expiry_lock() on migration_base) indeed seems to > implement > the optimization implied by the above, namely avoid the lock/unlock > in > case base == migration_base: > > > - if (timer->is_soft && base && base->cpu_base) { > > + if (timer->is_soft && base != &migration_base) { > > But the followup patch (hrtimer: Add a missing bracket and hide > `migration_base on !SMP) to fix the build on !SMP [the missing > bracket > part seems to have been fixed when backporting the above to 4.19-rt] > replaces that logic by > > +static inline bool is_migration_base(struct hrtimer_clock_base > *base) > +{ > + return base == &migration_base; > +} > + > ... > - if (timer->is_soft && base != &migration_base) { > + if (timer->is_soft && is_migration_base(base)) { > > in the SMP case, i.e. the exact opposite condition. One of these > can't > be correct. > > Assuming the followup patch was wrong and the condition should have > read > > timer->is_soft && !is_migration_base(base) > > while keeping is_migration_base() false on !SMP might explain the > problem I see. But I'd like someone who knows this code to chime in. >
I don't know this code, but I think you're correct - the followup patch reversed the condition by forgetting the !. So, does your problem go away when you make that change? Tom > Thanks, > Rasmus
