[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20101208004428.408716476@clark.site>
Date: Tue, 07 Dec 2010 16:43:47 -0800
From: Greg KH <gregkh@...e.de>
To: linux-kernel@...r.kernel.org, stable@...nel.org
Cc: stable-review@...nel.org, torvalds@...ux-foundation.org,
akpm@...ux-foundation.org, alan@...rguk.ukuu.org.uk,
Jiri Slaby <jslaby@...e.cz>, Alan Cox <alan@...ux.intel.com>
Subject: [041/127] TTY: restore tty_ldisc_wait_idle
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jiri Slaby <jslaby@...e.cz>
commit 100eeae2c5ce23b4db93ff320ee330ef1d740151 upstream.
It was removed in 65b770468e98 (tty-ldisc: turn ldisc user count into
a proper refcount), but we need to wait for last user to quit the
ldisc before we close it in tty_set_ldisc.
Otherwise weird things start to happen. There might be processes
waiting in tty_read->n_tty_read on tty->read_wait for input to appear
and at that moment, a change of ldisc is fatal. n_tty_close is called,
it frees read_buf and the waiting process is still in the middle of
reading and goes nuts after it is woken.
Previously we prevented close to happen when others are in ldisc ops
by tty_ldisc_wait_idle in tty_set_ldisc. But the commit above removed
that. So revoke the change and test whether there is 1 user (=we), and
allow the close then.
We can do that without ldisc/tty locks, because nobody else can open
the device due to TTY_LDISC_CHANGING bit set, so we in fact wait for
everybody to leave.
I don't understand why tty_ldisc_lock would be needed either when the
counter is an atomic variable, so this is a lockless
tty_ldisc_wait_idle.
On the other hand, if we fail to wait (timeout or signal), we have to
reenable the halted ldiscs, so we take ldisc lock and reuse the setup
path at the end of tty_set_ldisc.
Signed-off-by: Jiri Slaby <jslaby@...e.cz>
Acked-by: Linus Torvalds <torvalds@...ux-foundation.org>
Tested-by: Sebastian Andrzej Siewior <bigeasy@...akpoint.cc>
LKML-Reference: <20101031104136.GA511@...millionaire.breakpoint.cc>
LKML-Reference: <1287669539-22644-1-git-send-email-jslaby@...e.cz>
Cc: Alan Cox <alan@...ux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>
---
drivers/char/tty_ldisc.c | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
--- a/drivers/char/tty_ldisc.c
+++ b/drivers/char/tty_ldisc.c
@@ -45,6 +45,7 @@
static DEFINE_SPINLOCK(tty_ldisc_lock);
static DECLARE_WAIT_QUEUE_HEAD(tty_ldisc_wait);
+static DECLARE_WAIT_QUEUE_HEAD(tty_ldisc_idle);
/* Line disc dispatch table */
static struct tty_ldisc_ops *tty_ldiscs[NR_LDISCS];
@@ -81,6 +82,7 @@ static void put_ldisc(struct tty_ldisc *
return;
}
local_irq_restore(flags);
+ wake_up(&tty_ldisc_idle);
}
/**
@@ -522,6 +524,23 @@ static int tty_ldisc_halt(struct tty_str
}
/**
+ * tty_ldisc_wait_idle - wait for the ldisc to become idle
+ * @tty: tty to wait for
+ *
+ * Wait for the line discipline to become idle. The discipline must
+ * have been halted for this to guarantee it remains idle.
+ */
+static int tty_ldisc_wait_idle(struct tty_struct *tty)
+{
+ int ret;
+ ret = wait_event_interruptible_timeout(tty_ldisc_idle,
+ atomic_read(&tty->ldisc->users) == 1, 5 * HZ);
+ if (ret < 0)
+ return ret;
+ return ret > 0 ? 0 : -EBUSY;
+}
+
+/**
* tty_set_ldisc - set line discipline
* @tty: the terminal to set
* @ldisc: the line discipline
@@ -616,7 +635,16 @@ int tty_set_ldisc(struct tty_struct *tty
flush_scheduled_work();
+ retval = tty_ldisc_wait_idle(tty);
+
mutex_lock(&tty->ldisc_mutex);
+
+ /* handle wait idle failure locked */
+ if (retval) {
+ tty_ldisc_put(new_ldisc);
+ goto enable;
+ }
+
if (test_bit(TTY_HUPPED, &tty->flags)) {
/* We were raced by the hangup method. It will have stomped
the ldisc data and closed the ldisc down */
@@ -649,6 +677,7 @@ int tty_set_ldisc(struct tty_struct *tty
tty_ldisc_put(o_ldisc);
+enable:
/*
* Allow ldisc referencing to occur again
*/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists