Re: Stop scheduler on panic

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 :)

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