On Mon, Nov 30, 2020 at 5:03 AM Peter Zijlstra <pet...@infradead.org> wrote:
>
> > But but but...
> >
> > do_idle() # IRQs on
> > local_irq_disable(); # IRQs off
> > defaul_idle_call() # IRQs off
> lockdep_hardirqs_on(); # IRQs off, but lockdep things they're on
> > arch_cpu_idle() # IRQs off
> > enabled_wait() # IRQs off
> > raw_local_save() # still off
> > psw_idle() # very much off
> > ext_int_handler # get an interrupt ?!?!
> rcu_irq_enter() # lockdep thinks IRQs are on <- FAIL
>
> I can't much read s390 assembler, but ext_int_handler() has a
> TRACE_IRQS_OFF, which would be sufficient to re-align the lockdep state
> with the actual state, but there's some condition before it, what's that
> test and is that right?
I think that "psw_idle()" enables interrupts, exactly like x86 does.
See my previous email.
But no, I can't read s390 asm either. IBM is notorious for making up
odd IBM-only incomprehensible names. When "oi" means "or immediate", I
personally start suspecting that there were some "happy drugs"
involved.
To make matters worse, some of the assembly code in psw_idle isn't
even assembly code, it's machine code, with "BPON" being an
alternative instruction definition with just the hex encoding for the
machine code instruction rather than any actual human-legible
instruction encoding.
Of course, when the "human-legible" instructions are "oi", I guess hex
codes aren't all that much less legible..
s390 programmers must be some super-human breed. Or, alternatively,
they are munching happy pills by the truck-load to get over the pain
;)
Linus
