Date: Thu, 16 Mar 2006 12:08:25 +0800 From: David Xu <davidxu@freebsd.org> To: John Baldwin <jhb@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: <200603161208.25942.davidxu@freebsd.org> In-Reply-To: <200603150852.23540.jhb@freebsd.org> References: <200603140400.k2E40LiR095530@repoman.freebsd.org> <200603150730.36818.davidxu@freebsd.org> <200603150852.23540.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. David Xu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200603161208.25942.davidxu>