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

[Finn Thain <fthain@linux-m68k.org>]

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.