Re: [PATCH v6 1/1] MIPS: Fix idle VS timer enqueue

[Frederic Weisbecker]

Le Wed, Mar 19, 2025 at 03:42:16PM +0100, Thomas Bogendoerfer a écrit :
> On Wed, Mar 19, 2025 at 03:06:12PM +0100, Frederic Weisbecker wrote:
> > Le Wed, Mar 19, 2025 at 12:07:07PM +0100, Thomas Bogendoerfer a écrit :
> > > On Sat, Mar 15, 2025 at 08:40:02PM +0100, Marco Crivellari wrote:
> > > > MIPS re-enables interrupts on its idle routine and performs
> > > > a TIF_NEED_RESCHED check afterwards before putting the CPU to sleep.
> > > > 
> > > > The IRQs firing between the check and the 'wait' instruction may set the
> > > > TIF_NEED_RESCHED flag. In order to deal with this possible race, IRQs
> > > > interrupting __r4k_wait() rollback their return address to the
> > > > beginning of __r4k_wait() so that TIF_NEED_RESCHED is checked
> > > > again before going back to sleep.
> > > > 
> > > > However idle IRQs can also queue timers that may require a tick
> > > > reprogramming through a new generic idle loop iteration but those timers
> > > > would go unnoticed here because __r4k_wait() only checks
> > > > TIF_NEED_RESCHED. It doesn't check for pending timers.
> > > 
> > > can you give a commit ID, when this change got introduced ?
> > 
> > That would be:
> > 
> >      Fixes: c65a5480ff29 ("[MIPS] Fix potential latency problem due to non-atomic cpu_wait.")
> 
> hmm, so even then checking TIF_NEED_RESCHED wasn't enough  (we are talking
> about 2.6.27) ?

Right, the real issue dates even back earlier because the aforementioned fix only
handled the TIF_NEED_RESCHED part of the problem but the timer part of the problem
was there before.

However nohz was introduced only earlier the same year (2.6.21). We probably
don't need to dig much further...

> 
> Thomas.
> 
> -- 
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea.                                                [ RFC1925, 2.3 ]