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?
>> #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:
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
- 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