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.
