From owner-svn-src-all@FreeBSD.ORG Tue Sep 21 16:54:02 2010 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4D421065670; Tue, 21 Sep 2010 16:54:02 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 9941B8FC21; Tue, 21 Sep 2010 16:54:02 +0000 (UTC) Received: from [192.168.1.2] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o8LGs1qT029510; Tue, 21 Sep 2010 09:54:01 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4C98E324.8090803@feral.com> Date: Tue, 21 Sep 2010 09:53:56 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: John Baldwin References: <201009211507.o8LF7iVv097676@svn.freebsd.org> <4C98D200.4040909@freebsd.org> <201009211250.40704.jhb@freebsd.org> In-Reply-To: <201009211250.40704.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.67.166.1]); Tue, 21 Sep 2010 09:54:01 -0700 (PDT) Cc: svn-src-head@FreeBSD.org, mdf@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Andriy Gapon Subject: Re: svn commit: r212964 - head/sys/kern X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2010 16:54:02 -0000 > Err, I don't think _mtx_lock_sleep() is guarded in that fashion? I have an > old patch to do that but have never committed it. If we want that we should > probably change rwlocks and sxlocks to have also not block when panicstr is > set. Seems to me you are backing into interesting territory here- getting a bit more like Solaris. If you *do* do this, then you really *do* need to stop all other CPUs when you panic, or else it's likely you'll double panic more often than not.