Re: [Bug 1878645] Re: null-ptr dereference in tcg_handle_interrupt

[Alexander Bulekov]

On 200629 2000, Alex Bennée wrote:
> 
> Alexander Bulekov <1878645@bugs.launchpad.net> writes:
> 
> > I don't think this is a qtest-specific error: 
> > cat << EOF| qemu-system-i386 -M q35 -nographic -serial none -monitor stdio
> > o/4 0xcf8 0x8400f841
> > o/4 0xcfc 0xaa215d6d
> > o/4 0x6d30 0x2ef8ffbe
> > o/1 0xb2 0x20
> > EOF
> >
> > ...
> > Segmentation fault
> 
> Both this and the qtest have the same problem of depending on
> current_cpu which is a TLS variable which will never be correct from the
> qtest or monitor context. There are only a few other cases.

Ah that makes sense. It probably isn't a real issue, but I'll send
patches with the changes you suggested below.
Thank you

> sun4m:cpu_halt_signal does:
> 
>     if (level && current_cpu) {
>         cpu_interrupt(current_cpu, CPU_INTERRUPT_HALT);
>     }
> 
> pxa2xx:pxa2xx_pwrmode_write does a bare:
> 
>     /* Suspend */
>     cpu_interrupt(current_cpu, CPU_INTERRUPT_HALT);
> 
> but given the context has a CPUARMState *env it could arguably use that
> to derive current_cpu but as it's only triggered by a system register
> write you can't actually trigger from a monitor/qtest command.
> 
> I would suggest either:
> 
>         } else if (current_cpu) {
>             cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI);
>         }
> 
> or possibly:
> 
>         } else {
>             cpu_interrupt(current_cpu ? current_cpu : first_cpu, 
> CPU_INTERRUPT_SMI);
>         }
> 
> if you really care about triggering a real IRQ from outside the CPU context.
> 
> -- 
> Alex Bennée
>