Date: Sun, 29 Dec 1996 00:48:10 +0800 From: Peter Wemm <peter@spinner.dialix.com> To: Michael Petry <petry@netwolf.NetMasters.com> Cc: freebsd-smp@freebsd.org, louie@wa3ymh.transsys.com Subject: Re: psignal under SMP Message-ID: <199612281648.AAA00835@spinner.DIALix.COM> In-Reply-To: Your message of "Sat, 28 Dec 1996 11:41:51 EST." <199612281641.LAA28588@netwolf.NetMasters.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Michael Petry wrote:
>
> While showing a buddy the SMP build of FreeBSD we came across an interesting
> bug. I opened two windows from my work back to my dual P6-180 system at home
.
> I compiled the program
>
> main() {
> foo:
> goto foo;
> }
>
> I exec'd it in the second window and was showing that things were still snapp
y
> in the primary window. I then went back to the second window and tried to
> kill the process. No go. Hmmm, scratched head and went back to the primary
> and ran a few utilities to find out what was going on. Boom!! The process in
> the second window dies. My buddy and I kicked the issue around for a while
> and then it hit us. The hard cpu process had its signal posted, but never got
> rescheduled to see the signals because it was happy and cozy running on the
> second processor. My running of some utilities were enough to force it off
> its cpu and cause it to be rescheduled and pickup its signal.
>
> Though this is an extreme case (no syscalls , just a hard cpu loop) We though
t
> some more and concluded that that it would reap havoc with processes that wer
e
> computing in wait of a SIGIOs on a relatively idle system.
>
> It looked to us like psignal.c would have to be made smarter to know not only
> if a process is runnable, but also if it is running on another CPU and be
> IPI'd.
Yep, this is entry #13 on the TODO list in the smp tree:
13. Send APIC->APIC irq when process is killed.
.. yeah.. this is pretty important if the process is running...
BTW, this is real panic potential. Given that cpu1 is running in a tight
loop in user mode and cpu0 sends it an "untrappable" signal, cpu0 can mark
the process data structures as "dead" and free them up since the process
obviously doesn't need to be scheduled again... If cpu1 then goes to
update the process stats.... boom!
Cheers,
-Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612281648.AAA00835>