Re: spinlock recursion when running q800 emulation in qemu

Finn Thain
2024-03-08T00:55:56Z

On Fri, 8 Mar 2024, Michael Schmitz wrote:

> > If interrupt nesting messed up its state, you won't know it by looking
> > at the stack after the fact.
>
> True, we may see the effect only on the next tick.
>
> But we may not need to invoke lock checker corruption in order to
> explain the recursion message.
>

Right. We can explain it in other ways.

> Reentering the VIA1 timer handler would re-run scheduler_tick(). If the
> prior run has not yet released the run queue lock, we'd get the
> recursion message.
>
> I realized (belatedly) that scheduler_tick() does not run the task
> itself but just causes a reschedule if appropriate, so the probability
> for this condition is quite low. The question is - does the VIA1 timer
> interrupt ever get reentered?
>
> Can you add a printk_once() warning when you see
> arch/m68k/mac/via.c:via_timer_handler() reentered, Guenter?
>

It's not possible for an interrupt handler to be interrupted unless by an
hard interrupt at a higher priority level. Maybe QEMU could be so broken
(?!) but recall that I saw this BUG on a Powerbook 180 ten years ago.

IMHO, Gueunter would do better to instrument the spinlock tests on the
assumption that the locking in arch/m68k really is correct.