Skip to contentSkip to conversation

WARNING: at drivers/tty/tty_ldisc.c:766 tty_ldisc_reinit+0x52/0x90() [3.0]

DISCUSSION Dave Jones 4 participants 5 messages Aug 28, 2011 – Oct 18, 2011 TTY layer and serial drivers

lore
Share & tools
lore

Dave Jones

author
#0 lore raw

Just saw this on a box that was recieving an rsync while I ssh'd in. The ssh session hung.

(version says 2.6.40, it's 3.0 in all but name)

Dave

WARNING: at drivers/tty/tty_ldisc.c:766 tty_ldisc_reinit+0x52/0x90()
Hardware name:         
Modules linked in: nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc p4_clockmod freq_table speedstep_lib nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack microcode serio_raw snd_hda_codec_realtek i2c_i801 snd_hda_intel snd_hda_codec iTCO_wdt snd_hwdep iTCO_vendor_support snd_seq snd_seq_device snd_pcm snd_timer snd r8169 soundcore mii snd_page_alloc pata_sil680 i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: mperf]
Pid: 1381, comm: sshd Not tainted 2.6.40-4.fc15.x86_64.debug #1
Call Trace:
 [<ffffffff81058e74>] warn_slowpath_common+0x83/0x9b
 [<ffffffff81058ea6>] warn_slowpath_null+0x1a/0x1c
 [<ffffffff812f8e18>] tty_ldisc_reinit+0x52/0x90
 [<ffffffff812f9415>] tty_ldisc_hangup+0x13f/0x1e1
 [<ffffffff812f21b6>] __tty_hangup+0x111/0x35f
 [<ffffffff812f2429>] tty_vhangup+0xe/0x10
 [<ffffffff812faade>] pty_close+0x128/0x132
 [<ffffffff812f3404>] tty_release+0x1d8/0x4dc
 [<ffffffff81087a2e>] ? lock_release_holdtime.part.8+0x6b/0x72
 [<ffffffff8100eebf>] ? native_sched_clock+0x34/0x36
 [<ffffffff8113cdb2>] fput+0x127/0x1f5
 [<ffffffff81139d90>] filp_close+0x70/0x7b
 [<ffffffff81139e91>] sys_close+0xf6/0x13b
 [<ffffffff814fdf02>] system_call_fastpath+0x16/0x1b
---[ end trace 639fa37f00e1dc5b ]---
#1 lore raw
Quoted 2 lines · Dave Jones

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?

Quoted 19 lines
WARNING: at drivers/tty/tty_ldisc.c:766 tty_ldisc_reinit+0x52/0x90()
Hardware name:
Modules linked in: nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc p4_clockmod freq_table speedstep_lib nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack microcode serio_raw snd_hda_codec_realtek i2c_i801 snd_hda_intel snd_hda_codec iTCO_wdt snd_hwdep iTCO_vendor_support snd_seq snd_seq_device snd_pcm snd_timer snd r8169 soundcore mii snd_page_alloc pata_sil680 i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: mperf]
Pid: 1381, comm: sshd Not tainted 2.6.40-4.fc15.x86_64.debug #1
Call Trace:
  [<ffffffff81058e74>] warn_slowpath_common+0x83/0x9b
  [<ffffffff81058ea6>] warn_slowpath_null+0x1a/0x1c
  [<ffffffff812f8e18>] tty_ldisc_reinit+0x52/0x90
  [<ffffffff812f9415>] tty_ldisc_hangup+0x13f/0x1e1
  [<ffffffff812f21b6>] __tty_hangup+0x111/0x35f
  [<ffffffff812f2429>] tty_vhangup+0xe/0x10
  [<ffffffff812faade>] pty_close+0x128/0x132
  [<ffffffff812f3404>] tty_release+0x1d8/0x4dc
  [<ffffffff81087a2e>] ? lock_release_holdtime.part.8+0x6b/0x72
  [<ffffffff8100eebf>] ? native_sched_clock+0x34/0x36
  [<ffffffff8113cdb2>] fput+0x127/0x1f5
  [<ffffffff81139d90>] filp_close+0x70/0x7b
  [<ffffffff81139e91>] sys_close+0xf6/0x13b
  [<ffffffff814fdf02>] system_call_fastpath+0x16/0x1b
Signature · 2 lines
js
suse labs
Quoted 1 line

From 4fe9f5edcd187fb29298b59698cb920f2baccc15 Mon Sep 17 00:00:00 2001

From: Jiri Slaby <[email protected]>
Date: Mon, 8 Aug 2011 16:00:59 +0200
Subject: [PATCH 1/1] TTY: tty_ldisc_wait_idle debug

Signed-off-by Jiri Slaby <[email protected]>
---
 drivers/tty/tty_ldisc.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)
drivers/tty/tty_ldisc.c +8 -1
index 512c49f..0b90801 100644
@@ -26,6 +26,7 @@
 #include <linux/bitops.h>
 #include <linux/delay.h>
 #include <linux/seq_file.h>
+#include <linux/ratelimit.h>
 
 #include <linux/uaccess.h>
 #include <asm/system.h>

@@ -758,11 +759,17 @@ static void tty_reset_termios(struct tty_struct *tty)
 static int tty_ldisc_reinit(struct tty_struct *tty, int ldisc)
 {
 	struct tty_ldisc *ld = tty_ldisc_get(ldisc);
+	int ret;
 
 	if (IS_ERR(ld))
 		return -1;
 
-	WARN_ON_ONCE(tty_ldisc_wait_idle(tty));
+	ret = tty_ldisc_wait_idle(tty);
+	if (ret)
+		printk_ratelimited(KERN_DEBUG "%s: refcount of %ps is still %d\n",
+				__func__,
+				tty->ldisc->ops,
+				atomic_read(&tty->ldisc->users));
 
 	tty_ldisc_close(tty, tty->ldisc);
 	tty_ldisc_put(tty->ldisc);
Signature · 1 line
1.7.6.1
#2 lore raw
Quoted 6 lines · Jiri Slaby
Quoted 3 lines · Dave Jones

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

Quoted 33 lines
Quoted 11 lines
WARNING: at drivers/tty/tty_ldisc.c:766 tty_ldisc_reinit+0x52/0x90()
Hardware name:
Modules linked in: nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc

p4_clockmod freq_table speedstep_lib nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack microcode serio_raw snd_hda_codec_realtek i2c_i801 snd_hda_intel snd_hda_codec iTCO_wdt snd_hwdep iTCO_vendor_support snd_seq snd_seq_device snd_pcm snd_timer snd r8169 soundcore mii snd_page_alloc pata_sil680 i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last
unloaded: mperf]
Pid: 1381, comm: sshd Not tainted 2.6.40-4.fc15.x86_64.debug #1

Quoted 15 lines
Call Trace:
 [<ffffffff81058e74>] warn_slowpath_common+0x83/0x9b
 [<ffffffff81058ea6>] warn_slowpath_null+0x1a/0x1c
 [<ffffffff812f8e18>] tty_ldisc_reinit+0x52/0x90
 [<ffffffff812f9415>] tty_ldisc_hangup+0x13f/0x1e1
 [<ffffffff812f21b6>] __tty_hangup+0x111/0x35f
 [<ffffffff812f2429>] tty_vhangup+0xe/0x10
 [<ffffffff812faade>] pty_close+0x128/0x132
 [<ffffffff812f3404>] tty_release+0x1d8/0x4dc
 [<ffffffff81087a2e>] ? lock_release_holdtime.part.8+0x6b/0x72
 [<ffffffff8100eebf>] ? native_sched_clock+0x34/0x36
 [<ffffffff8113cdb2>] fput+0x127/0x1f5
 [<ffffffff81139d90>] filp_close+0x70/0x7b
 [<ffffffff81139e91>] sys_close+0xf6/0x13b
 [<ffffffff814fdf02>] system_call_fastpath+0x16/0x1b

--
js
suse labs

Signature · 2 lines
Regards
Dave
#3 lore raw
Quoted 6 lines · Dave Young
Quoted 5 lines · Jiri Slaby
Quoted 3 lines · Dave Jones

Just saw this on a box that was recieving an rsync while I ssh'd in. The ssh session hung.

Quoted 8 lines
Quoted 1 line

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?

drivers/tty/n_tty.c +3 -0
@@ -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,

Signature · 1 line
js
#4 lore raw
Quoted 14 lines · Jiri Slaby
Quoted 13 lines · Dave Young
Quoted 6 lines · Jiri Slaby
Quoted 3 lines · Dave Jones

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:

Quoted 7 lines
Quoted 1 line

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

I just startx from tty1

bash-4.1$ ps ax|grep getty
 1626 tty2     Ss+    0:00 /sbin/agetty 38400 tty2 linux
 1627 tty3     Ss+    0:00 /sbin/agetty 38400 tty3 linux
 1628 tty4     Ss+    0:00 /sbin/agetty 38400 tty4 linux
 1629 tty5     Ss+    0:00 /sbin/agetty 38400 tty5 linux
 1630 tty6     Ss+    0:00 /sbin/agetty 38400 tty6 linux
 3586 tty1     Ss+    0:00 /sbin/agetty 38400 tty1 linux
 5928 pts/1    S+     0:00 grep getty

What do you means of "die"? X11 died indeed as I saw.

Quoted 37 lines

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?

drivers/tty/n_tty.c +3 -0
@@ -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

Signature · 2 lines
Regards
Dave