Messages in this thread | | | Date | Sun, 23 Jan 2005 16:15:12 +0300 | From | Sergey Vlasov <> | Subject | Re: kernel oops! |
| |
On Sat, 22 Jan 2005 22:43:50 -0800 (PST) Linus Torvalds wrote:
> Interesting. That last call trace entry is the call in > pty_chars_in_buffer() to > > /* The ldisc must report 0 if no characters available to be read */ > count = to->ldisc.chars_in_buffer(to); > > and it looks like it has jumped to address zero. > > However, we _just_ compared the fn pointer to zero immediately before, and > while there could certainly have been a race that cleared it in between > the test and the call, normally we wouldn't even have re-loaded the value > at all, but kept it in a register instead. > > That said, it does act like a race. Somebody clearing the ldisc and racing > with somebody using it? > > Can you do a > > gdb vmlinux > > disassemble pty_chars_in_buffer > > to show what it looks like (whether it reloads the value, and what the > registers are - it looks like either %eax or %edi is all zeroes, but I'd > like to verify that it matches your code generation). > > Alan? Any ideas? The tty_select() path seems to take a ldisc reference, > but does that guarantee that the ldisc won't _change_?
tty_poll() grabs ldisc reference for the tty it was called with; however, in this case pty_chars_in_buffer() accesses another ldisc (tty->link->ldisc) without grabbing a reference to it. BTW, many other pty_* functions do the same thing.
Is calling tty_ldisc_ref(tty->link) safe here? There is a comment warning about possible deadlocks before pty_write(). [unhandled content-type:application/pgp-signature] | |