From owner-cvs-all@FreeBSD.ORG Thu Mar 16 13:34:15 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 975C416A400; Thu, 16 Mar 2006 13:34:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id D52F143D45; Thu, 16 Mar 2006 13:34:14 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k2GDYD4u045718; Thu, 16 Mar 2006 08:34:13 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: David Xu Date: Thu, 16 Mar 2006 08:34:05 -0500 User-Agent: KMail/1.8.3 References: <200603140400.k2E40LiR095530@repoman.freebsd.org> <200603150852.23540.jhb@freebsd.org> <200603161208.25942.davidxu@freebsd.org> In-Reply-To: <200603161208.25942.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200603160834.06672.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1335/Wed Mar 15 23:58:43 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-3.5 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx 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 13:34:15 -0000 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 =A0<>< =A0http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org