]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
Fix low-level locking during panics.
authorbde <bde@FreeBSD.org>
Sat, 2 Jun 2018 08:38:59 +0000 (08:38 +0000)
committerbde <bde@FreeBSD.org>
Sat, 2 Jun 2018 08:38:59 +0000 (08:38 +0000)
commit14f65346d34995b7b62859ca0af85b330ff136c1
treefa30d31501856516f762fd29274fe1926b426f4f
parenta8efb181f4d494eb27bebac65ddc1f4c956071ce
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.
sys/dev/syscons/syscons.c