Bruce Evans b9cedb46e2 Fix low-level locking during panics.
The SCHEDULER_STOPPED() hack breaks locking generally, and
mtx_trylock_*() especially.  When mtx_trylock_*() returns nonzero,
naive code version here trusts it to have worked.  But when
SCHEDULER_STOPPED() is true, mtx_trylock_*() returns 1 without doing
anything.  Then mtx_unlock_*() crashes especially badly attempting to
unlock iff the error is detected, since mutex unlocking functions don't
check SCHEDULER_STOPPED().

syscons already didn't trust mtx_trylock_spin(), but it was missing the
logic to turn on sp->kdb_locked when turning off sp->mtx_locked during
panics.  It also used panicstr instead of SCHEDULER_LOCKED because I
thought that panicstr was more fragile.  They only differ for a window
of lines in panic(), and in broken cases where stop_cpus_hard() in panic()
didn't work.
2018-06-02 08:38:59 +00:00
..
2018-06-01 19:42:59 +00:00
2018-05-24 17:06:00 +00:00
2018-05-06 00:45:41 +00:00
2018-05-22 15:49:23 +00:00
2018-04-13 20:30:49 +00:00
2018-05-28 02:34:38 +00:00
2018-05-15 13:30:59 +00:00
2017-12-30 19:27:22 +00:00
2018-05-17 10:13:18 +00:00
2018-03-14 18:27:06 +00:00
2018-03-28 07:59:16 +00:00
2017-11-30 20:33:45 +00:00
2018-05-25 19:00:28 +00:00
2017-11-30 20:33:45 +00:00
2018-04-08 22:59:34 +00:00
2018-05-25 03:34:33 +00:00
2017-10-21 07:23:45 +00:00
2017-11-30 20:33:45 +00:00
2018-04-13 20:30:49 +00:00
2018-04-28 17:43:20 +00:00
2018-04-23 16:38:27 +00:00
2018-01-03 00:56:30 +00:00
2018-01-13 16:31:07 +00:00
2018-05-24 10:20:42 +00:00