Stop scheduler on panic

[John Baldwin]

On 12/4/11 5:11 PM, Andriy Gapon wrote:
> on 02/12/2011 17:30 mdf at FreeBSD.org said the following:
>> On Fri, Dec 2, 2011 at 2:05 AM, Andriy Gapon<avg at 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