cvs commit: src/sys/kern subr_sleepqueue.c

[John Baldwin]

On Tuesday 02 March 2004 09:02 pm, Dag-Erling Smørgrav wrote:
> John Baldwin <jhb at FreeBSD.org> writes:
> > I never saw that case and this is the first I've heard of it.  ddb tends
> > to freeze when you enter it holding a spin lock.  Do you have any log
> > messages from the mis-matched locks for msleep?
>
> Mismatched locks to msleep(0xc9376000, pause):
>   old 0xc935d06c (process lock), new 0xc64d1e2c (process lock)
> Stack backtrace:
> sleepq_add(c748cdc0,c9376000,c64d1e2c,c05bbdf1,0) at sleepq_add+0x1ee
> msleep(c9376000,c64d1e2c,168,c05bbdf1,0) at msleep+0x19f
> kern_sigsuspend(c64d23f0,0,0,0,0) at kern_sigsuspend+0xa1
> linux_rt_sigsuspend(c64d23f0,ebb20d14,2,279b5,200212) at
> linux_rt_sigsuspend+0x4f syscall(2f,bfbf002f,bfbf002f,28636da8,bfbfe0c0) at
> syscall+0x129
> Xint0x80_syscall() at Xint0x80_syscall+0x1d
> --- syscall (179), eip = 0x288379b6, esp = 0xbfbfe0a0, ebp = 0xbfbfe0a8 ---
>
> DES

I see the bug.  Here are the msleep's on p_sigacts:

> grep msleep kern_sig.c
        error = msleep(ps, &p->p_mtx, PPAUSE|PCATCH, "sigwait", hz);
        while (msleep(p->p_sigacts, &p->p_mtx, PPAUSE|PCATCH, "pause", 0) == 
0)
        while (msleep(p->p_sigacts, &p->p_mtx, PPAUSE|PCATCH, "opause", 0) == 
0)

Now realize that p_sigacts is a refcount'd struct shared between rfork'd 
processes (i.e. Linux threads).  The sleep's don't actually get woken up via 
a wakeup, they get woken up via a signal, so the wait channel is really a 
dummy.  Try changing those three msleep's to sleep on &ps and &p->p_sigacts 
and see if that fixes the panic.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org