lkml.org 
[lkml]   [2005]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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]
\
 
 \ /
  Last update: 2005-03-22 14:09    [W:0.105 / U:1.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site