From owner-cvs-all@FreeBSD.ORG Thu Mar 16 04:08:32 2006 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2C7716A400; Thu, 16 Mar 2006 04:08:32 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AD2943D46; Thu, 16 Mar 2006 04:08:32 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from localhost.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k2G48UnP043066; Thu, 16 Mar 2006 04:08:32 GMT (envelope-from davidxu@freebsd.org) From: David Xu To: John Baldwin Date: Thu, 16 Mar 2006 12:08:25 +0800 User-Agent: KMail/1.8.2 References: <200603140400.k2E40LiR095530@repoman.freebsd.org> <200603150730.36818.davidxu@freebsd.org> <200603150852.23540.jhb@freebsd.org> In-Reply-To: <200603150852.23540.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603161208.25942.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 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2006 04:08:32 -0000 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