Re: Spinlock debug, was Re: [PATCH RFC] m68k: skip kernel premption if interrupts were disabled

Finn Thain
2024-03-28T02:47:00Z

On Thu, 28 Mar 2024, Michael Schmitz wrote:

> On 28/03/24 12:29, Finn Thain wrote:
> > On Wed, 27 Mar 2024, Michael Schmitz wrote:
> >
> >> Now none of this has got us any closer to a solution for the spinlock
> >> recursion bug...
> >>
> > It appears that the spinlock recursion check really works: I am able
> > to reproduce the following failure every time I paste too much text
> > into the qemu console.
> >
> > This looks like a straight-forward driver bug, whereby the "irq flood"
> > printk() results in pmz_console_write() attempting to lock the
> > spinlock already locked by pmz_interrupt(). The spinlock at 0x62e140
> > is the one in struct uart_port.
>
> That's a legitimate recursion warning then. pmz_console_write() should
> not retake the lock already held when called from interrupt context.
>
> I agree the recursion checks did work correctly in this case.
>
> Spinlock recursion in scheduler_tick() doesn't look possible from
> reentering scheduler_tick() through code in its call path, so the
> mechanism there would be different.
>
> We did rule out the VIA timer interrupt (or MFP timer A interrupt)
> getting reentered, right?
>

I never added an assertion to prove that because I don't have a way to
reproduce the "spinlock recursion" BUG reported by Guenter.