svn commit: r331298 - head/sys/dev/syscons

[Warner Losh]

On Wed, Mar 21, 2018 at 2:27 PM, Konstantin Belousov <kostikbel at gmail.com>
wrote:

> On Thu, Mar 22, 2018 at 04:53:22AM +1100, Bruce Evans wrote:
> > Serial console drivers with fast interrupt handlers have much more
> > broken locking for ddb special keys.  It is invalid to either drop locks
> > or call the "any" function from a fast interrupt handler, but buggy
> > serial console drivers calls kbd_alt_break(), and that now calls
> > shutdown_nice() and other functions that cannot be called from a fast
> > interrupt handler.  ddb keys supply most of the shutdown_nice()
> > functionality for serial consoles, and there are no escape sequence to
> > get this without ddb or maybe another debugger, so these bugs don't
> > affect most users.
> >
> > Handling this correctly requires much the same fix as an unsafe signal
> > handler, and fixes have much the same problems -- not much more than
> > setting a flag is safe, and the flag might never be looked at if the
> > system is in a bad state.  However, if a nice shutdown is possible then
> > the sytem must be in a good enough state to poll for flags.
>
> Are you saying that fast interrupt handlers call shutdown_nice() ?  This
> is the quite serious bug on its own.  To fix it, shutdown_nice() should
> use a fast taskqueue to schedule the task which would lock the process
> and send the signal.
>

Is there some way we know we're in a fast interrupt handler? If so, it
should be simple to fix. If not, then there's an API change ahead of us...

But bde is right: the system has to be in good enough shape to cope. I
wonder if we should put that coping into kdb_reboot() instead. It's only an
issue for <CR> TILDE ^R, which is a fairly edge case.

Warner