NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

>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 <>
>Release:        NetBSD 4.99.50 (20080127)
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

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.


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


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...

Home | Main Index | Thread Index | Old Index