Re: [GIT pull] locking/urgent for v5.10-rc6

[Linus Torvalds]

On Mon, Nov 30, 2020 at 5:03 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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