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