lkml.org 
[lkml]   [2005]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: kernel oops!


On Mon, 24 Jan 2005, Alan Cox wrote:
>
> Almost every user of tty_ldisc_ref_* doesn't need to lock two objects and
> the code at that layer has no knowledge of pty/tty pairs.

Hmm.. It looks different to me - almost all users of the xxx_ref_wait()
that act on pty's _do_ seem to use tty->link->ldisc.*()". The one counter-
example seems to be pty_set_termios().

But I only did a quick grep in drivers/char, so there might be other users
out there I didn't even think of.

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

> I'm dubious this is the actual bug although vhangup on a pty might
> trigger it I guess.

ierdnah - can you verify whether either of my silly patches seems to have
made any difference?

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

I'd assume that it's when the other end is changed to using the
"ppp_[sync_]ldisc", both of which do actually have a NULL
"chars_in_buffer". (Alternatively, maybe "chars_in_buffer" isn't actually
NULL at all - the backtrace might be confused by either some really
strange memory corruption or a tail-call to a NULL function pointer by
some other line discipline thing, although quite frankly I think that
sounds extremely unlikely).

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

driver->chars_in_buffer = op->chars_in_buffer ? : default_chars_in_buffer;

(where the default just returns zero) thing or something.

That would even speed up the normal cases (no need to test the pointer for
NULL).

Linus



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

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.042 / U:1.816 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site