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 <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"