From: Aristeu Rozanski <aris@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: Peter Hurley <peter@hurleysoftware.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jslaby@suse.cz>
Subject: [PATCH] n_tty_read: check for hanging tty while waiting for input
Date: Tue, 17 Feb 2015 16:06:09 -0500 [thread overview]
Message-ID: <20150217210609.GA13666@redhat.com> (raw)
If the console has a canonical reader and the respective tty hangs up,
it'll waste a wake up and will never release the last ldisc reference so
the hangup process can finish:
n_tty_read():
(..)
add_wait_queue(&tty->read_wait, &wait);
while (nr) {
(..)
if (!input_available_p(tty, 0)) {
if (test_bit(TTY_OTHER_CLOSED, &tty->flags)) {
up_read(&tty->termios_rwsem);
tty_flush_to_ldisc(tty);
down_read(&tty->termios_rwsem);
if (!input_available_p(tty, 0)) {
retval = -EIO;
break;
}
} else {
-> if (tty_hung_up_p(file))
break;
this won't work because file->f_op never gets set to &hung_up_tty_fops:
__tty_hangup():
spin_lock(&tty_files_lock);
/* This breaks for file handles being sent over AF_UNIX sockets ? */
list_for_each_entry(priv, &tty->tty_files, list) {
filp = priv->file;
if (filp->f_op->write == redirected_tty_write)
cons_filp = filp;
-> if (filp->f_op->write != tty_write)
-> continue;
closecount++;
__tty_fasync(-1, filp, 0); /* can't block */
-> filp->f_op = &hung_up_tty_fops;
}
spin_unlock(&tty_files_lock);
refs = tty_signal_session_leader(tty, exit_session);
/* Account for the p->signal references we killed */
while (refs--)
tty_kref_put(tty);
/*
* it drops BTM and thus races with reopen
* we protect the race by TTY_HUPPING
*/
-> tty_ldisc_hangup(tty);
So while the canonical read waits for input, it'll sleep, be awaken by
tty_ldisc_hangup() and then immediately going back to sleep without
dropping the reference to the ldisc gained on tty_read(). This isn't
noticiable in a non canonical read due that it'll eventually timeout.
The proposed patch checks for TTY_HUPPING flag in order to leave if
there's no input.
This is easily reproduced by opening /dev/console (my test case was a
virtual machine with serial console), setting as canonical and waiting
on a read(). Then, in another session, killing agetty that is running on
ttyS0 which will issue a hangup.
[ 240.439045] INFO: task (agetty):1323 blocked for more than 120 seconds.
[ 240.439569] Not tainted 3.13.0-rc3+ #11
[ 240.439972] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 240.440596] (agetty) D ffff88007fd94440 0 1323 1 0x00000080
[ 240.441253] ffff88007bca1c50 0000000000000086 ffff88007989b0c0 0000000000014440
[ 240.441857] ffff88007bca1fd8 0000000000014440 ffff88007989b0c0 ffff88007989b0c0
[ 240.442561] ffff88007ad46c30 7fffffffffffffff 0000000000000001 ffff88007ad46c28
[ 240.443296] Call Trace:
[ 240.443506] [<ffffffff815c8c99>] schedule+0x29/0x70
[ 240.443883] [<ffffffff815c7f59>] schedule_timeout+0x209/0x2d0
[ 240.444395] [<ffffffff810974b5>] ? check_preempt_curr+0x85/0xa0
[ 240.444850] [<ffffffff810974e9>] ? ttwu_do_wakeup+0x19/0xd0
[ 240.445343] [<ffffffff8109764d>] ? ttwu_do_activate.constprop.80+0x5d/0x70
[ 240.445868] [<ffffffff810995eb>] ? try_to_wake_up+0xeb/0x2b0
[ 240.446363] [<ffffffff815cbdaa>] ldsem_down_write+0xda/0x227
[ 240.446797] [<ffffffff81099822>] ? default_wake_function+0x12/0x20
[ 240.447359] [<ffffffff815cc43d>] tty_ldisc_lock_pair_timeout+0x7d/0x100
[ 240.447861] [<ffffffff8136e519>] tty_ldisc_hangup+0xc9/0x220
[ 240.448355] [<ffffffff81365463>] __tty_hangup+0x363/0x4b0
[ 240.448768] [<ffffffff81367cc5>] tty_ioctl+0x865/0xbb0
[ 240.449219] [<ffffffff811bb52a>] ? do_filp_open+0x3a/0x90
[ 240.449634] [<ffffffff811bd900>] do_vfs_ioctl+0x2e0/0x4c0
[ 240.450066] [<ffffffff8124ea76>] ? file_has_perm+0x86/0xa0
[ 240.450543] [<ffffffff811bdb61>] SyS_ioctl+0x81/0xa0
[ 240.450921] [<ffffffff815d4b69>] system_call_fastpath+0x16/0x1b
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Aristeu Rozanski <aris@redhat.com>
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 0f74945..4fb909d 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -2189,6 +2189,8 @@ static ssize_t n_tty_read(struct tty_struct *tty, struct file *file,
} else {
if (tty_hung_up_p(file))
break;
+ if (test_bit(TTY_HUPPING, &tty->flags))
+ break;
if (!timeout)
break;
if (file->f_flags & O_NONBLOCK) {
next reply other threads:[~2015-02-17 21:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-17 21:06 Aristeu Rozanski [this message]
2015-02-17 21:28 ` Peter Hurley
2015-02-17 21:50 ` Aristeu Rozanski
2015-02-17 22:35 ` Peter Hurley
2015-02-18 14:58 ` Aristeu Rozanski
2015-02-18 15:40 ` Peter Hurley
2015-02-18 15:56 ` Aristeu Rozanski
2015-02-18 16:38 ` Peter Hurley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150217210609.GA13666@redhat.com \
--to=aris@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=peter@hurleysoftware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome