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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/