On Mon, Jan 11, 2021 at 01:25:59PM +0100, Peter Zijlstra wrote: > On Sat, Jan 09, 2021 at 03:05:34AM +0100, Frederic Weisbecker wrote: > > The idle loop has several need_resched() checks that make sure we don't > > miss a rescheduling request. This means that any wake up performed on > > the local runqueue after the last generic need_resched() check is going > > to have its rescheduling silently ignored. This has happened in the > > past with rcu kthreads awaken from rcu_idle_enter() for example. > > > > Perform sanity checks to report these situations. > > I really don't like this.. > > - it's too specific to the actual reschedule condition, any wakeup this > late is dodgy, not only those that happen to cause a local > reschedule. Right. > > - we can already test this with unwind and checking against __cpuidle > > - moving all of __cpuidle into noinstr would also cover this. And we're > going to have to do that anyway. Ok then, I'll wait for that instead. > > > +void noinstr sched_resched_local_assert_allowed(void) > > +{ > > + if (this_rq()->resched_local_allow) > > + return; > > + > > > + /* > > + * Idle interrupts break the CPU from its pause and > > + * rescheduling happens on idle loop exit. > > + */ > > + if (in_hardirq()) > > + return; > > + > > + /* > > + * What applies to hardirq also applies to softirq as > > + * we assume they execute on hardirq tail. Ksoftirqd > > + * shouldn't have resched_local_allow == 0. > > + * We also assume that no local_bh_enable() call may > > + * execute softirqs inline on fragile idle/entry > > + * path... > > + */ > > + if (in_serving_softirq()) > > + return; > > + > > + WARN_ONCE(1, "Late current task rescheduling may be lost\n"); > > That seems like it wants to be: > > WARN_ONCE(in_task(), "..."); Right! But I guess I'll drop that patch now. Thanks.