Date: Wed, 21 Mar 2018 18:36:21 -0600 From: Warner Losh <imp@bsdimp.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Bruce Evans <brde@optusnet.com.au>, Warner Losh <imp@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r331298 - head/sys/dev/syscons Message-ID: <CANCZdfrY9PQ-FUApReGeFqwH%2BdoSUN5AtvF0ag1rD09sKYq6gg@mail.gmail.com> In-Reply-To: <20180321202752.GO76926@kib.kiev.ua> References: <201803211447.w2LElDcK091988@repo.freebsd.org> <20180322024846.S4293@besplex.bde.org> <20180321202752.GO76926@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 21, 2018 at 2:27 PM, Konstantin Belousov <kostikbel@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrY9PQ-FUApReGeFqwH%2BdoSUN5AtvF0ag1rD09sKYq6gg>