Keyboard input needs Giant locking, and that is not possible to do
correctly here. Use mtx_trylock() and proceed unlocked as before if
we can't acquire Giant (non-recursively), except in kdb mode don't
even try to acquire Giant. Everything here is a hack, but it often
works. Even if mtx_trylock() succeeds, this might be a LOR.
Keyboard input also needs screen locking, to handle screen updates
and switches. Add this, using the same simplistic screen locking
as for sc_cnputc().
Giant must be acquired before the screen lock, and the screen lock
must be dropped when calling the keyboard driver (else it would get a
harmless LOR if it tries to acquire Giant). It was intended that sc
cn open/close hide the locking calls, and they do for i/o functions
functions except for this complication.
Non-console keyboard input is still only Giant-locked, with screen
locking in some called functions. This is correct for the keyboard
parts only.
When Giant cannot be acquired properly, atkbd and kbdmux tend to race
and work (they assume that the caller acquired Giant properly and don't
try to acquire it again or check that it has been acquired, and the
races rarely matter), while ukbd tends to deadlock or panic (since it
does the opposite, and has other usb threads to deadlock with).
The keyboard (Giant) locking here does very little, but the screen
locking completes screen locking for console mode except for not
detecting or handling deadlock.
a95582c6fd