Subject: Re: kern/28541: mi_switch() can deadlock on biglock
To: Pavel Cahyna <firstname.lastname@example.org>
From: Manuel Bouyer <email@example.com>
Date: 12/05/2004 22:32:56
On Sun, Dec 05, 2004 at 10:29:41PM +0100, Pavel Cahyna wrote:
> > CPU 0:
> > acquire
> > spinlock_aquire_count
> > mi_switch
> > ltsleep
> > sbwait
> > soreceive
> > soo_read
> > dofileread
> > sys_read
> > syscall_plain
> > CPU0 is trying to aquire again kernel_lock, while CPU1 has it, and tries
> > to send an IPI to CPU0.
> > But I don't know how this would prevent CPU0 from receiving an IPI.
> Because during whole execution of spinlock_acquire_count, CPU 0 is at
> spllock (INTERLOCK_ACQUIRE does spllock) and spllock is defined as
> splhigh, which probably blocks IPIs.
On x86, splhigh() doens't block IPIs:
#define IPL_HIGH 0xd /* everything */
#define IPL_SERIAL 0xd /* serial */
#define IPL_IPI 0xe /* inter-processor interrupts */
If this was the problem, we could run into this each time the 2 CPU competes
for the kernel_lock. I've only seen it with mi_swicth() in the path, so
I think mi_switch() is doing something special here ...
Manuel Bouyer <firstname.lastname@example.org>
NetBSD: 26 ans d'experience feront toujours la difference