Re: spinlock recursion when running q800 emulation in qemu

Michael Schmitz
2024-03-08T08:06:54Z

Hi Finn,

Am 08.03.2024 um 13:56 schrieb Finn Thain:
>> 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

Right - not sure why I remembered interrupt handlers lowering the IPL
there.

That leaves other users of the run queue lock. Queuing new tasks would
be one obvious such user for the init task, but that is run with IRQs
disabled (we'd see these warnings a lot more else). And comparing with
how early I see the 'cblist_init_generic: Setting adjustable number of
callback queues' message in my boot logs, this may all happen too early
for init to start queuing tasks.

> (?!) but recall that I saw this BUG on a Powerbook 180 ten years ago.

I'll take a look at the scheduler code from that era (though probably
not much has changed since).

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

I've come to agree - maybe logging any run queue locks taken by the init
task with IRQs enabled might help?

Cheers,

Michael