Hi, Arnd,
On Thu, Aug 12, 2021 at 8:30 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> On Thu, Aug 12, 2021 at 1:17 PM Huacai Chen <chenhuacai@xxxxxxxxx> wrote:
> > On Tue, Jul 6, 2021 at 7:09 PM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> > >
> > > On Tue, Jul 06, 2021 at 12:16:37PM +0200, Arnd Bergmann wrote:
> > > > On Tue, Jul 6, 2021 at 6:18 AM Huacai Chen <chenhuacai@xxxxxxxxxxx> wrote:
> > > >
> > > > > +void arch_cpu_idle(void)
> > > > > +{
> > > > > + local_irq_enable();
> > > > > + __arch_cpu_idle();
> > > > > +}
> > > >
> > > > This looks racy: What happens if an interrupt is pending and hits before
> > > > entering __arch_cpu_idle()?
> > >
> > > They fix it up in their interrupt handler by moving the IP over the
> > > actual IDLE instruction..
> > >
> > > Still the above is broken in that local_irq_enable() will have all sorts
> > > of tracing, but RCU is disabled at this point, so it is still very much
> > > broken.
> > This is a sad story, the idle instruction cannot execute with irq
> > disabled, we can only copy ugly code from MIPS.
>
> Maybe you can avoid that tracing problem if you move the irq-enable
> and subsequent need_resched() check into the assembler code.
>
> Another option would be to have the actual idle logic implemented
> in firmware that runs at a higher privilege level and provides a
> hypercall interface to the kernel with the normal behavior (
> enter with irq disabled, wait until irq).
We have some problems with trace options enabled before, but it seems
some problems disappear after we refactor the irq/syscall code by
using generic entry code. :)
Huacai.
>
> Arnd
