Look at tty_io.c:
* Failures after this point use release_mem to clean up, so
* there's no need to null out the local pointers.
*/
driver->table[idx] = tty;
+ /* FIXME: this is broken and
+ probably causes ^D bug. tty->private_date does not (yet) point
+ to a console, if keypress comes now, await armagedon.
+
+ also, driver->table is accessed from interrupt for vt case,
+ and this does not look like atomic access at all. */
+
if (!*tp_loc)
*tp_loc = tp;
if (!*ltp_loc)
Keyboard driver access console_driver.table from interrupt, and this
is uprotected. Keyboard interrupt can call
c01950fe con_flush_chars + ??
c019b5d4 n_tty_receive_buf + ??
c0196ea6 do_self + ??
c0196923 kbd_handle_scancode + ??
con_flush_chars, which in turn tries to access tty->driver_data, which
is NULL at this point (it is initialized much later), and you get Oops
in IRQ and completely locked system. Not good. And not too easy to
resolve. (This is for keyboard case, is it possible that similar bugs
occur for other tty's?)
Pavel
-- I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/