From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 22:11:42 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41C85106566B; Sun, 4 Dec 2011 22:11:42 +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 26EE88FC08; Sun, 4 Dec 2011 22:11:40 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA00568; Mon, 05 Dec 2011 00:11:39 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RXKHb-000I7o-E0; Mon, 05 Dec 2011 00:11:39 +0200 Message-ID: <4EDBF01B.8000802@FreeBSD.org> Date: Mon, 05 Dec 2011 00:11:39 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: mdf@FreeBSD.org References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201112011349.50502.jhb@freebsd.org> <4ED7E6B0.30400@FreeBSD.org> <201112011553.34432.jhb@freebsd.org> <4ED7F4BC.3080206@FreeBSD.org> <4ED855E6.20207@FreeBSD.org> <4ED8A306.9020801@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, John Baldwin Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 22:11:42 -0000 on 02/12/2011 17:30 mdf@FreeBSD.org said the following: > On Fri, Dec 2, 2011 at 2:05 AM, Andriy Gapon wrote: >> on 02/12/2011 06:36 John Baldwin said the following: >>> Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true when kdb was >>> active). But I think these two changes should cover critical_exit() ok. >>> >> >> I attempted to start a discussion about this a few times already :-) >> Should we treat kdb context the same as SCHEDULER_STOPPED context (in the >> current definition) ? That is, skip all locks in the same fashion? >> There are pros and contras. > > Does kdb pause all CPUs with an interrupt (NMI or regular interrupt, I > can no longer remember...) when it enters? If so, then I'd say > whether it enters via sysctl or panic doesn't matter. It's in a > special environment where nothing else is running, which is what is > needed for proper exploration of the machine (via breakpoint, for > debugging a hang, etc). > > Maybe the question is, why wouldn't SCHEDULER_STOPPED be true > regardless of how kdb is entered? I think that the discussion that followed has clarified this point a bit. SCHEDULER_STOPPED perhaps needs a better name :-) Currently it, the name, reflects the state of the scheduler, but not why the scheduler is stopped and not the greater state of the system ("in panic"), nor how we should handle that state ("bypass locking"). So I'd love something like BYPASS_LOCKING_BECAUSE _SCHEDULER_IS_STOPPED_IN_PANIC haven't it be so unwieldy :) When the kdb_active is true the scheduler is stopped, true. But it is a different kind of system state from which we potentially may want to continue normal operation. So a lot more care is needed and simply bypassing locks is probably not a solution. I guess that some day in the distant future we might decide that a built-in debugger is for critical/abnormal situations only... -- Andriy Gapon