Date: Thu, 08 Dec 2011 10:40:19 -0500 From: John Baldwin <jhb@FreeBSD.org> To: Andriy Gapon <avg@FreeBSD.org> Cc: mdf@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: Stop scheduler on panic Message-ID: <4EE0DA63.8000305@FreeBSD.org> In-Reply-To: <4EDBF01B.8000802@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> <CAMBSHm_Cw1dSfoRVBo0bw_jAtB3Xrw0s%2BDZfFGKyCaXJS6F2CQ@mail.gmail.com> <4EDBF01B.8000802@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/4/11 5:11 PM, Andriy Gapon wrote:
> on 02/12/2011 17:30 mdf@FreeBSD.org said the following:
>> On Fri, Dec 2, 2011 at 2:05 AM, Andriy Gapon<avg@freebsd.org> 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 :)
Oh, hmm. Yes, being in the debugger should not potentially corrupt lock
state, so in that sense it is a weaker stop.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EE0DA63.8000305>