Re: Stop scheduler on panic

2011/12/4 Andriy Gapon <avg_at_freebsd.org>:
> on 21/11/2011 18:58 Attilio Rao said the following:
>> I would be very in favor about having a 'thread trampoline for KDB',
>> thus that it can use locks.
>
> I keep hearing the suggestion to add this trampoline, but I admit that I do not
> understand its technical meaning in this context.  And also how it helps with
> the locking.  So I will appreciate an explanation!  Thanks!

kdb_trap() now runs in interrupt context, my suggestion was to just to
give KDB its own context (a new kernel thread) and yield its execution
when KDB needs to be entered, this way it is possible to use locking
and avoid functions duplications.

In theory, this avoids constructing complicate algorithms to be
lockless when implementing primitives KDB should use.
However, I now realize a problem: if we want to stop CPUs we don't
really want to acquire locks anyway because of CPU restart.
Likely, the KDB trampoline is not a good option for this reason and we
should work instead on getting KDB functions to be totally lockless.

Another thing I'm considering is, however, the entrypoint for KDB.
When I looked into it months ago I thought there is a mismatch between
kdb_enter() (which should disable CPUs) and other ways to enter KDB
(maybe some paths calling directly kdb_trap()?). We must offer an
unified policy and entrypoint, being likely to disable CPUs when
entering it.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein