cvs commit: src/sys/kern kern_exit.c kern_thread.c

[John Baldwin]

On Wednesday 15 March 2006 11:08 pm, David Xu wrote:
> On Wednesday 15 March 2006 21:52, John Baldwin wrote:
> > > I was very upset, and forgot to put your name in the log, apologize.
> > > Note that because the thread has detached itself from scheduler,
> > > calling PROC_UNLOCK in theory is not safe, so I have moved
> > > up this patch code a bit.
> >
> > Ok.  I think the PROC_UNLOCK might be ok in practice though because
> > we are in a critical section, so we won't preempt when we unlock
> > the mutex and will keep executing until we get to the cpu_throw.
> >
> > --
>
> I don't agree, from scheduler side, if current thread does not have any
> scheduler assoiciated data, and the setrunqueue may access current
> thread's scheduler data, it will have trouble, though current 4BSD
> scheduler does not have any sensitive data stored in the per-thread,
> but another new scheduler may not work in this way, assuming that a
> thread which is in critical region and unlocks a mutex won't use per-thread
> scheduler data is dangerous, in fact, I saw the kernel was crashed in
> turnstile code after the current thread detaching itself from its ksegroup
> and starts to call PROC_UNLOCK.

I'm not sure why setrunqueue() of some other thread X != curthread
would care about the state of curthread since it should bail out of
preemption checking as soon as it sees that curthread is in a critical
section.

In any case, you can always move the function call in question down
further below the proc unlock.  One change I had in my patches was
to stick the PROC_UNLOCK() after the big if-statement so there was
just one of them instead of doing it at the end of each case in the
if-else.

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