Messages in this thread Patch in this message | | | Date | Mon, 17 Oct 2011 22:40:34 +0200 | From | Jiri Slaby <> | Subject | Re: WARNING: at drivers/tty/tty_ldisc.c:766 tty_ldisc_reinit+0x52/0x90() [3.0] |
| |
On 10/09/2011 08:59 AM, Dave Young wrote: > On Fri, Sep 2, 2011 at 4:59 AM, Jiri Slaby <jslaby@suse.cz> wrote: >> On 08/28/2011 03:15 PM, Dave Jones wrote: >>> >>> Just saw this on a box that was recieving an rsync while I ssh'd in. >>> The ssh session hung. >> >> Yes, could you apply the attached debug patch and post a dmesg output? > > I see this problem as well, the debug patch reports the refcount is 2 > > You can produce the WARN as below: > in xterm run: > > exec 0<>/dev/console 1<>/dev/console 2<>/dev/console
Thanks for the info. I suppose your console is something where also some getty runs. Then the warning is perfectly OK. And with the hunk below constifying timing, I guess your system dies after the 5s timeout of tty_ldisc_wait_idle. (You don't need to test the patch, just confirm there is a getty running on the console.)
So actually I'm not sure what we should do there to not die. Perhaps wait infinitely? Because the user wants to steal a terminal?
--- a/drivers/tty/n_tty.c +++ b/drivers/tty/n_tty.c @@ -49,6 +49,7 @@ #include <linux/file.h> #include <linux/uaccess.h> #include <linux/module.h> +#include <linux/delay.h>
#include <asm/system.h>
@@ -1575,6 +1576,7 @@ static int n_tty_open(struct tty_struct *tty)
/* These are ugly. Currently a malloc failure here can panic */ if (!tty->read_buf) { + msleep(100); tty->read_buf = kzalloc(N_TTY_BUF_SIZE, GFP_KERNEL); if (!tty->read_buf) return -ENOMEM; @@ -1815,6 +1817,7 @@ do_it_again: /* FIXME: does n_tty_set_room need locking ? */ n_tty_set_room(tty); timeout = schedule_timeout(timeout); + msleep(20); BUG_ON(!tty->read_buf); continue; }
thanks, -- js
| |