On 22-May-2002 Dag-Erling Smorgrav wrote: > Miguel Mendez <[EMAIL PROTECTED]> writes: >> I've attached both a backtrace and my dmesg. Is any extra info needed? > > RTFAQ. > >> #10 0xc01d5899 in panic (fmt=0xc02fed34 "setrunnable(2)") >> at ../../../kern/kern_shutdown.c:647 >> #11 0xc01dbde2 in setrunnable (td=0xd21952a0) at ../../../kern/kern_synch.c:800 >> #12 0xc01d8547 in psignal (p=0xd21951a0, sig=23) at ../../../kern/kern_sig.c:1517 > > Looks like a race: when psignal() was called, the process was stopped > or sleeping, but by the time setrunnable() was called, it was running. > Something is touching p_stat without acquiring sched_lock (psignal() > acquires it before examining p_stat, and holds it until it returns; > setrunnable() also acquires it - recusrively since psignal() already > holds it)
Actually, in DP1 psignal() might not have held it the entire time. I fixed that rather recently: revision 1.155 date: 2002/04/13 23:33:36; author: jhb; state: Exp; lines: +22 -36 - Change killpg1()'s first argument to be a thread instead of a process so we can use td_ucred. - In killpg1(), the proc lock is sufficient to check if p_stat is SZOMB or not. We don't need sched_lock. - Close some races in psignal(). In psignal() there is a big switch statement based on p_stat. All the different cases are assuming that the process (or thread) isn't going to change state out from under it. To ensure this is true, just lock sched_lock for the entire switch. We practically held it the entire time already anyways. This also simplifies the locking somewhat and actually results in fewer lock operations. - Allow signotify() to be called with the sched_lock held since psignal() now does that. - Use td_ucred in a couple of places. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
