Re: spinlock recursion when running q800 emulation in qemu

[Michael Schmitz <schmitzmic@gmail.com>]

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