Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Mar 2006 08:34:05 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        David Xu <davidxu@freebsd.org>
Cc:        cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org
Subject:   Re: cvs commit: src/sys/kern kern_exit.c kern_thread.c
Message-ID:  <200603160834.06672.jhb@freebsd.org>
In-Reply-To: <200603161208.25942.davidxu@freebsd.org>
References:  <200603140400.k2E40LiR095530@repoman.freebsd.org> <200603150852.23540.jhb@freebsd.org> <200603161208.25942.davidxu@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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-thre=
ad
> 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 !=3D 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.

=2D-=20
John Baldwin <jhb@FreeBSD.org> =A0<>< =A0http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200603160834.06672.jhb>