Page MenuHomeFreeBSD

vt: avoid grabbing locks for KERNEL_PANICKED() as well
Needs ReviewPublic

Authored by kevans on Fri, Jan 10, 4:34 AM.

Details

Reviewers
emaste
manu
jhb
Summary

This matches the precise conditional we use elsewhere; we can end up
trying to grab the console for a panic that isn't routed through kdb
with, e.g., an explicit call to panic() via a failed assertion or some
such. The scheduler's generally stopped by the time we try to do a
window switch, so we shouldn't try to do any of the normal locking.

Note that this doesn't mean we'll succeed at grabbing the console. If
i915kms is active, for instance, then we won't be able to switch to
ttyv0 to draw the panic message. This does avoid stacking an additional
unrelated panic on top of a panic that we're actually interested in,
though.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 61639
Build 58523: arc lint + arc unit

Event Timeline

I'm fine with this. Don't the locking implementations just bail without panicking though if a panic is already active, or is the nested panic not inside a lock but elsewhere?