From owner-svn-src-user@FreeBSD.ORG Wed May 25 14:36:44 2011 Return-Path: Delivered-To: svn-src-user@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 537E31065674; Wed, 25 May 2011 14:36:44 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 11EAB8FC1D; Wed, 25 May 2011 14:36:42 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA29335; Wed, 25 May 2011 17:36:41 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DDD13F9.5040800@FreeBSD.org> Date: Wed, 25 May 2011 17:36:41 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Attilio Rao References: <201105181508.p4IF8UoS096841@svn.freebsd.org> <20110518182441.GB2273@garage.freebsd.pl> <4DD4243C.4070301@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: src-committers@FreeBSD.org, Pawel Jakub Dawidek , svn-src-user@FreeBSD.org Subject: Re: svn commit: r222060 - in user/avg/xcpu/sys: kern sys X-BeenThere: svn-src-user@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the experimental " user" src tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:36:44 -0000 on 18/05/2011 23:06 Attilio Rao said the following: > However I think that TDF_INPANIC handling is not optimal. > You should really acquire thread_lock otherwise you are going to break > choosethread() concurrency. > > I would prefer to make TDF_INPANIC a private flag and just use it with > curthread, if possible, but I still don't have a good way to resolve > choosethread() (I would dig the runqueue adding path and resolve the > problem later in the codeflow, I think). I've been thinking about this. I think that in the new world where only one thread runs after panic we could just reduce TD_IS_INPANIC to panicstr != NULL, TDF_INPANIC could be removed altogether along with the check in choosethread(). But for some initial period I would like to have an option to disable CPU stopping (to protect from possible bugs, regressions, etc) and for that I would like to keep TDF_INPANIC. The flag could be set without thread_lock() because we still allow only one thread to be in/after panic. But I completely agree with you that it is cleaner to move TDF_INPANIC to private flags. So the first step: TDF_INPANIC => to private flags Some time in the future: TDF_INPANIC => removed TD_IS_INPANIC => panicstr != NULL -- Andriy Gapon