kern/37915: vt100 + wscons + tty vmlocking changes = panic

[dholland%eecs.harvard.edu@localhost]

>Number:         37915
>Category:       kern
>Synopsis:       vt100 + wscons + tty vmlocking changes = panic
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jan 30 01:30:00 +0000 2008
>Originator:     David A. Holland <dholland%eecs.harvard.edu@localhost>
>Release:        NetBSD 4.99.50 (20080127)
>Organization:
>Environment:
System: NetBSD valkyrie 4.99.50 NetBSD 4.99.50 (VALKYRIE) #3: Sun Jan 27 
14:54:46 EST 2008 root@valkyrie:/usr/src/sys/arch/amd64/compile/VALKYRIE amd64
Architecture: x86_64
Machine: amd64
>Description:

Sending some VT100 control sequences to wscons will panic the kernel.

The problem is that ttwrite() holds tty_lock while calling ttstart();
this makes its way down to wsemul_vt100_handle_csi(), which for
several sequences that report stuff back calls wsdisplay_emulinput(),
which calls ttyinput(), which tries to get tty_lock again.

>How-To-Repeat:

Run some program that sends such a sequence (e.g. tset) or echo one
manually, while logged in on the console.

>Fix:

One could make the lock recursive, but that's gross. Probably the best
bet would be to make another entry in linesw (l_rintlocked?) for when
one already holds the tty lock, and use that in wsdisplay_emulinput().

Or just ("just") hunt down all (other) callers of l_rint and make them
get the lock first. The comment above tty_input suggests this is the
eventual plan anyway...