On 12/4/11 5:11 PM, Andriy Gapon wrote:
on 02/12/2011 17:30 m...@freebsd.org said the following:
On Fri, Dec 2, 2011 at 2:05 AM, Andriy Gapon<a...@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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
