Re: kernel oops!

[Alan Cox]

On Llu, 2005-01-24 at 17:58, Linus Torvalds wrote:
> On Mon, 24 Jan 2005, Alan Cox wrote:
> While doing that, I did notice that all the other tty ops do take the 
> kernel lock still - both read() and write() do. I wonder if we should just 
> make poll() consistent, regardless of other issues (obviously, the nicest 
> way to make it consistent would be to remove the kernel lock from the 
> read/write paths, but I assume nobody wants to go through the locking).

The lock is needed for the console at least and for some driver level
bits.

> And I don't think it can be vhangup - that wouldn't clear the
> chars_in_buffer function pointer (it might change it to the 
> n_tty_chars_in_buffer or something by resetting to N_TTY).

True - that would need an ldisc.close and the vhangup no longer does
that.

> So another potential fix is to just make all tty line disciplines always 
> have a valid "chars_in_buffer" pointer. We could even do automatically in 
> "tty_set_operations()", ie just do a

Not really. I'm in n_tty ->chars_in_buffer and the race occurs -> I'm
dead
as I'm already running the wrong chars_in_buffer function on CPU #0 when
CPU #1
comes along and flips ldisc. Holding the right locks matters here. We
also
need both locks holding really for tty/pty pairs because pty_write wants
to
output to the ldisc of the other side. Treating no ldisc as no
characters
seems very sane however and is easy to code up - if the ldisc_get fails
we
can sleep on the ldisc level wait queue then retry. Ugly enough to want
to
hide the contents in tty_io.c but doable. (When I get time - likely to
be 
a couple of weeks if nobody does it first)

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/