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:

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
- 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

Reply via email to