Re: kernel oops!

[Sergey Vlasov <vsu@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 1498 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]