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().
pgprNeK4PSxNY.pgp
Description: PGP signature
