linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 1/6] TTY: serial, remove BTM from wait_until_sent
@ 2011-07-14 12:35 Jiri Slaby
  2011-07-14 12:35 ` [PATCH v2 2/6] TTY: msm_serial, remove unneeded console set Jiri Slaby
                   ` (6 more replies)
  0 siblings, 7 replies; 19+ messages in thread
From: Jiri Slaby @ 2011-07-14 12:35 UTC (permalink / raw)
  To: gregkh
  Cc: jirislaby, linux-serial, linux-kernel, Jiri Slaby, Alan Cox,
	Arnd Bergmann, Andreas Bombe

During the BKL removal process, the BKL was switched to tty_lock
(BTM). Now we should start pruning the BTM further. Let's start with
wait_until_sent of the serial layer. This will allow us to switch to
the tty port helpers and thus clean it up much.

In wait_until_sent there are some uport members accessed, but neither
of them is protected by BTM at the location they are set ('=>' means
function call):
* uport->fifosize (set in tty_ioctl => uart_ioctl => uart_set_info)
* uport->type (set in add_one_port prior to tty_register_device)
* uport->timeout (set usually in tty_ioctl => tty_mode_ioctl =>
  tty_set_termios => uart_set_termios => uart_change_speed =>
  uport->ops->set_termios => uart_update_timeout)
* call to uport->ops->tx_empty()

If the tx_empty hook needs some lock to protect accesses to registers,
it should take &uport->lock spinlock like 8250 does. Otherwise there
still might be races e.g. with ISRs.

This should also fix the issue Andreas is seeing (BTM in comparison to
BKL doesn't have any hidden functionality like unlocking during
sleeping).

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
References: https://lkml.org/lkml/2011/5/25/562
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andreas Bombe <aeb@debian.org>
---
 drivers/tty/serial/serial_core.c |   30 +++++++-----------------------
 1 files changed, 7 insertions(+), 23 deletions(-)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index db7912c..2cbf1bd 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -57,7 +57,7 @@ static struct lock_class_key port_lock_key;
 
 static void uart_change_speed(struct tty_struct *tty, struct uart_state *state,
 					struct ktermios *old_termios);
-static void __uart_wait_until_sent(struct uart_port *port, int timeout);
+static void uart_wait_until_sent(struct tty_struct *tty, int timeout);
 static void uart_change_pm(struct uart_state *state, int pm_state);
 
 /*
@@ -1304,16 +1304,8 @@ static void uart_close(struct tty_struct *tty, struct file *filp)
 	tty->closing = 1;
 	spin_unlock_irqrestore(&port->lock, flags);
 
-	if (port->closing_wait != ASYNC_CLOSING_WAIT_NONE) {
-		/*
-		 * hack: open-coded tty_wait_until_sent to avoid
-		 * recursive tty_lock
-		 */
-		long timeout = msecs_to_jiffies(port->closing_wait);
-		if (wait_event_interruptible_timeout(tty->write_wait,
-				!tty_chars_in_buffer(tty), timeout) >= 0)
-			__uart_wait_until_sent(uport, timeout);
-	}
+	if (port->closing_wait != ASYNC_CLOSING_WAIT_NONE)
+		tty_wait_until_sent(tty, msecs_to_jiffies(port->closing_wait));
 
 	/*
 	 * At this point, we stop accepting input.  To do this, we
@@ -1329,7 +1321,7 @@ static void uart_close(struct tty_struct *tty, struct file *filp)
 		 * has completely drained; this is especially
 		 * important if there is a transmit FIFO!
 		 */
-		__uart_wait_until_sent(uport, uport->timeout);
+		uart_wait_until_sent(tty, uport->timeout);
 	}
 
 	uart_shutdown(tty, state);
@@ -1363,8 +1355,10 @@ done:
 	mutex_unlock(&port->mutex);
 }
 
-static void __uart_wait_until_sent(struct uart_port *port, int timeout)
+static void uart_wait_until_sent(struct tty_struct *tty, int timeout)
 {
+	struct uart_state *state = tty->driver_data;
+	struct uart_port *port = state->uart_port;
 	unsigned long char_time, expire;
 
 	if (port->type == PORT_UNKNOWN || port->fifosize == 0)
@@ -1416,16 +1410,6 @@ static void __uart_wait_until_sent(struct uart_port *port, int timeout)
 	}
 }
 
-static void uart_wait_until_sent(struct tty_struct *tty, int timeout)
-{
-	struct uart_state *state = tty->driver_data;
-	struct uart_port *port = state->uart_port;
-
-	tty_lock();
-	__uart_wait_until_sent(port, timeout);
-	tty_unlock();
-}
-
 /*
  * This is called with the BKL held in
  *  linux/drivers/char/tty_io.c:do_tty_hangup()
-- 
1.7.6



^ permalink raw reply related	[flat|nested] 19+ messages in thread

* [PATCH v2 2/6] TTY: msm_serial, remove unneeded console set
  2011-07-14 12:35 [PATCH v2 1/6] TTY: serial, remove BTM from wait_until_sent Jiri Slaby
@ 2011-07-14 12:35 ` Jiri Slaby
  2011-07-14 12:35 ` [PATCH v2 3/6] TTY: serial, remove tasklet for tty_wakeup Jiri Slaby
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 19+ messages in thread
From: Jiri Slaby @ 2011-07-14 12:35 UTC (permalink / raw)
  To: gregkh; +Cc: jirislaby, linux-serial, linux-kernel, Jiri Slaby, Alan Cox

It doesn't make sense to set console to uart_port in console->setup.
At that time the console is set by uart_add_one_port already.

The call chain looked like:
uart_add_one_port()
  uport->cons = drv->cons;   <= once
  uart_configure_port()
    register_console()
     console->setup()
       port->cons = co;      <= second time

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Alan Cox <alan@linux.intel.com>
---
 drivers/tty/serial/msm_serial.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
index e6ba838..29cbfd8 100644
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -804,8 +804,6 @@ static int __init msm_console_setup(struct console *co, char *options)
 	if (unlikely(!port->membase))
 		return -ENXIO;
 
-	port->cons = co;
-
 	msm_init_clock(port);
 
 	if (options)
-- 
1.7.6



^ permalink raw reply related	[flat|nested] 19+ messages in thread

* [PATCH v2 3/6] TTY: serial, remove tasklet for tty_wakeup
  2011-07-14 12:35 [PATCH v2 1/6] TTY: serial, remove BTM from wait_until_sent Jiri Slaby
  2011-07-14 12:35 ` [PATCH v2 2/6] TTY: msm_serial, remove unneeded console set Jiri Slaby
@ 2011-07-14 12:35 ` Jiri Slaby
  2011-07-19 16:34   ` Alan Cox
  2011-07-14 12:35 ` [PATCH v2 4/6] TTY: ami_serial, remove BTM from wait_until_sent Jiri Slaby
                   ` (4 subsequent siblings)
  6 siblings, 1 reply; 19+ messages in thread
From: Jiri Slaby @ 2011-07-14 12:35 UTC (permalink / raw)
  To: gregkh; +Cc: jirislaby, linux-serial, linux-kernel, Jiri Slaby, Alan Cox

tty_wakeup can be called from any context. So there is no need to have
an extra tasklet for calling that. Hence save some space and remove
the tasklet completely.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Alan Cox <alan@linux.intel.com>
---
 drivers/tty/serial/serial_core.c |   20 +-------------------
 include/linux/serial_core.h      |    1 -
 2 files changed, 1 insertions(+), 20 deletions(-)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 2cbf1bd..4786232 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -72,7 +72,7 @@ void uart_write_wakeup(struct uart_port *port)
 	 * closed.  No cookie for you.
 	 */
 	BUG_ON(!state);
-	tasklet_schedule(&state->tlet);
+	tty_wakeup(state->port.tty);
 }
 
 static void uart_stop(struct tty_struct *tty)
@@ -107,12 +107,6 @@ static void uart_start(struct tty_struct *tty)
 	spin_unlock_irqrestore(&port->lock, flags);
 }
 
-static void uart_tasklet_action(unsigned long data)
-{
-	struct uart_state *state = (struct uart_state *)data;
-	tty_wakeup(state->port.tty);
-}
-
 static inline void
 uart_update_mctrl(struct uart_port *port, unsigned int set, unsigned int clear)
 {
@@ -250,11 +244,6 @@ static void uart_shutdown(struct tty_struct *tty, struct uart_state *state)
 	}
 
 	/*
-	 * kill off our tasklet
-	 */
-	tasklet_kill(&state->tlet);
-
-	/*
 	 * Free the transmit buffer page.
 	 */
 	if (state->xmit.buf) {
@@ -2277,8 +2266,6 @@ int uart_register_driver(struct uart_driver *drv)
 		port->ops = &uart_port_ops;
 		port->close_delay     = 500;	/* .5 seconds */
 		port->closing_wait    = 30000;	/* 30 seconds */
-		tasklet_init(&state->tlet, uart_tasklet_action,
-			     (unsigned long)state);
 	}
 
 	retval = tty_register_driver(normal);
@@ -2439,11 +2426,6 @@ int uart_remove_one_port(struct uart_driver *drv, struct uart_port *uport)
 	 */
 	uport->type = PORT_UNKNOWN;
 
-	/*
-	 * Kill the tasklet, and free resources.
-	 */
-	tasklet_kill(&state->tlet);
-
 	state->uart_port = NULL;
 	mutex_unlock(&port_mutex);
 
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index a5c3114..76e1103 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -384,7 +384,6 @@ struct uart_state {
 	int			pm_state;
 	struct circ_buf		xmit;
 
-	struct tasklet_struct	tlet;
 	struct uart_port	*uart_port;
 };
 
-- 
1.7.6



^ permalink raw reply related	[flat|nested] 19+ messages in thread

* [PATCH v2 4/6] TTY: ami_serial, remove BTM from wait_until_sent
  2011-07-14 12:35 [PATCH v2 1/6] TTY: serial, remove BTM from wait_until_sent Jiri Slaby
  2011-07-14 12:35 ` [PATCH v2 2/6] TTY: msm_serial, remove unneeded console set Jiri Slaby
  2011-07-14 12:35 ` [PATCH v2 3/6] TTY: serial, remove tasklet for tty_wakeup Jiri Slaby
@ 2011-07-14 12:35 ` Jiri Slaby
  2011-07-14 12:35 ` [PATCH v2 5/6] TTY: remove tty_locked Jiri Slaby
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 19+ messages in thread
From: Jiri Slaby @ 2011-07-14 12:35 UTC (permalink / raw)
  To: gregkh
  Cc: jirislaby, linux-serial, linux-kernel, Jiri Slaby, Alan Cox,
	Andreas Bombe

The same as in "TTY: serial, remove BTM from wait_until_sent" we don't
need to take BTM in wait_until_sent of ami_serial. Exactly the same
as serial, ami_serial accesses some "info" members (xmit_fifo_size,
timeout), but their assignment on other places in the code is not
protected by BTM anyway.

So the BTM protects nothing here. This removal helps us to get rid of
tty_locked() and __big_tty_mutex_owner in the following patch. This
was suggested by Arnd.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Andreas Bombe <aeb@debian.org>
---
 drivers/tty/amiserial.c |   10 +---------
 1 files changed, 1 insertions(+), 9 deletions(-)

diff --git a/drivers/tty/amiserial.c b/drivers/tty/amiserial.c
index 2205795..6d43f55 100644
--- a/drivers/tty/amiserial.c
+++ b/drivers/tty/amiserial.c
@@ -1529,7 +1529,6 @@ static void rs_wait_until_sent(struct tty_struct *tty, int timeout)
 {
 	struct async_struct * info = tty->driver_data;
 	unsigned long orig_jiffies, char_time;
-	int tty_was_locked = tty_locked();
 	int lsr;
 
 	if (serial_paranoia_check(info, tty->name, "rs_wait_until_sent"))
@@ -1541,12 +1540,6 @@ static void rs_wait_until_sent(struct tty_struct *tty, int timeout)
 	orig_jiffies = jiffies;
 
 	/*
-	 * tty_wait_until_sent is called from lots of places,
-	 * with or without the BTM.
-	 */
-	if (!tty_was_locked)
-		tty_lock();
-	/*
 	 * Set the check interval to be 1/5 of the estimated time to
 	 * send a single character, and make it at least 1.  The check
 	 * interval should also be less than the timeout.
@@ -1586,8 +1579,7 @@ static void rs_wait_until_sent(struct tty_struct *tty, int timeout)
 			break;
 	}
 	__set_current_state(TASK_RUNNING);
-	if (!tty_was_locked)
-		tty_unlock();
+
 #ifdef SERIAL_DEBUG_RS_WAIT_UNTIL_SENT
 	printk("lsr = %d (jiff=%lu)...done\n", lsr, jiffies);
 #endif
-- 
1.7.6



^ permalink raw reply related	[flat|nested] 19+ messages in thread

* [PATCH v2 5/6] TTY: remove tty_locked
  2011-07-14 12:35 [PATCH v2 1/6] TTY: serial, remove BTM from wait_until_sent Jiri Slaby
                   ` (2 preceding siblings ...)
  2011-07-14 12:35 ` [PATCH v2 4/6] TTY: ami_serial, remove BTM from wait_until_sent Jiri Slaby
@ 2011-07-14 12:35 ` Jiri Slaby
  2011-07-19 16:35   ` Alan Cox
  2011-07-14 12:35 ` [PATCH v2 6/6] TTY: mxser+cyclades remove wait_until_sent debug code Jiri Slaby
                   ` (2 subsequent siblings)
  6 siblings, 1 reply; 19+ messages in thread
From: Jiri Slaby @ 2011-07-14 12:35 UTC (permalink / raw)
  To: gregkh; +Cc: jirislaby, linux-serial, linux-kernel, Jiri Slaby, Alan Cox

We used it really only serial and ami_serial. The rest of the
callsites were BUG/WARN_ONs to check if BTM is held. Now that we
pruned tty_locked from both of the real users, we can get rid of
tty_lock along with __big_tty_mutex_owner.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Alan Cox <alan@linux.intel.com>
---
 drivers/tty/serial/serial_core.c |    4 ----
 drivers/tty/tty_ldisc.c          |    1 -
 drivers/tty/tty_mutex.c          |   12 ------------
 drivers/tty/vt/selection.c       |    4 ++--
 include/linux/tty.h              |    2 --
 5 files changed, 2 insertions(+), 21 deletions(-)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 4786232..44c2963 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1245,8 +1245,6 @@ static void uart_close(struct tty_struct *tty, struct file *filp)
 	struct uart_port *uport;
 	unsigned long flags;
 
-	BUG_ON(!tty_locked());
-
 	if (!state)
 		return;
 
@@ -1411,7 +1409,6 @@ static void uart_hangup(struct tty_struct *tty)
 	struct tty_port *port = &state->port;
 	unsigned long flags;
 
-	BUG_ON(!tty_locked());
 	pr_debug("uart_hangup(%d)\n", state->uart_port->line);
 
 	mutex_lock(&port->mutex);
@@ -1498,7 +1495,6 @@ static int uart_open(struct tty_struct *tty, struct file *filp)
 	struct tty_port *port;
 	int retval, line = tty->index;
 
-	BUG_ON(!tty_locked());
 	pr_debug("uart_open(%d) called\n", line);
 
 	/*
diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index ef925d5..512c49f 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -450,7 +450,6 @@ static int tty_ldisc_open(struct tty_struct *tty, struct tty_ldisc *ld)
 	if (ld->ops->open) {
 		int ret;
                 /* BTM here locks versus a hangup event */
-		WARN_ON(!tty_locked());
 		ret = ld->ops->open(tty);
 		if (ret)
 			clear_bit(TTY_LDISC_OPEN, &tty->flags);
diff --git a/drivers/tty/tty_mutex.c b/drivers/tty/tty_mutex.c
index 3b2bb77..9ff986c 100644
--- a/drivers/tty/tty_mutex.c
+++ b/drivers/tty/tty_mutex.c
@@ -15,30 +15,18 @@
  * Don't use in new code.
  */
 static DEFINE_MUTEX(big_tty_mutex);
-struct task_struct *__big_tty_mutex_owner;
-EXPORT_SYMBOL_GPL(__big_tty_mutex_owner);
 
 /*
  * Getting the big tty mutex.
  */
 void __lockfunc tty_lock(void)
 {
-	struct task_struct *task = current;
-
-	WARN_ON(__big_tty_mutex_owner == task);
-
 	mutex_lock(&big_tty_mutex);
-	__big_tty_mutex_owner = task;
 }
 EXPORT_SYMBOL(tty_lock);
 
 void __lockfunc tty_unlock(void)
 {
-	struct task_struct *task = current;
-
-	WARN_ON(__big_tty_mutex_owner != task);
-	__big_tty_mutex_owner = NULL;
-
 	mutex_unlock(&big_tty_mutex);
 }
 EXPORT_SYMBOL(tty_unlock);
diff --git a/drivers/tty/vt/selection.c b/drivers/tty/vt/selection.c
index fb864e7..7a0a12a 100644
--- a/drivers/tty/vt/selection.c
+++ b/drivers/tty/vt/selection.c
@@ -301,6 +301,8 @@ int set_selection(const struct tiocl_selection __user *sel, struct tty_struct *t
 /* Insert the contents of the selection buffer into the
  * queue of the tty associated with the current console.
  * Invoked by ioctl().
+ *
+ * Locking: always called with BTM from vt_ioctl
  */
 int paste_selection(struct tty_struct *tty)
 {
@@ -310,8 +312,6 @@ int paste_selection(struct tty_struct *tty)
 	struct  tty_ldisc *ld;
 	DECLARE_WAITQUEUE(wait, current);
 
-	/* always called with BTM from vt_ioctl */
-	WARN_ON(!tty_locked());
 
 	console_lock();
 	poke_blanked_console();
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 44bc0c5..6d5eceb 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -600,8 +600,6 @@ extern long vt_compat_ioctl(struct tty_struct *tty,
 /* functions for preparation of BKL removal */
 extern void __lockfunc tty_lock(void) __acquires(tty_lock);
 extern void __lockfunc tty_unlock(void) __releases(tty_lock);
-extern struct task_struct *__big_tty_mutex_owner;
-#define tty_locked()		(current == __big_tty_mutex_owner)
 
 /*
  * wait_event_interruptible_tty -- wait for a condition with the tty lock held
-- 
1.7.6



^ permalink raw reply related	[flat|nested] 19+ messages in thread

* [PATCH v2 6/6] TTY: mxser+cyclades remove wait_until_sent debug code
  2011-07-14 12:35 [PATCH v2 1/6] TTY: serial, remove BTM from wait_until_sent Jiri Slaby
                   ` (3 preceding siblings ...)
  2011-07-14 12:35 ` [PATCH v2 5/6] TTY: remove tty_locked Jiri Slaby
@ 2011-07-14 12:35 ` Jiri Slaby
  2011-07-14 13:24 ` [PATCH v2 1/6] TTY: serial, remove BTM from wait_until_sent Arnd Bergmann
  2011-07-19  0:35 ` Andreas Bombe
  6 siblings, 0 replies; 19+ messages in thread
From: Jiri Slaby @ 2011-07-14 12:35 UTC (permalink / raw)
  To: gregkh; +Cc: jirislaby, linux-serial, linux-kernel, Jiri Slaby

It makes the code really ugly. And since it can be enabled only before
building and only in the source files, it can be barely used by users.
That said, I've not seen anybody to use it in the past few years.

This crap is copied to some more drivers over the tty tree. Since I'm
not their maintainer, I'm not sure if I should remove them too?

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 drivers/tty/cyclades.c |   12 +-----------
 drivers/tty/mxser.c    |   13 +------------
 2 files changed, 2 insertions(+), 23 deletions(-)

diff --git a/drivers/tty/cyclades.c b/drivers/tty/cyclades.c
index c0e8f2e..5beef49 100644
--- a/drivers/tty/cyclades.c
+++ b/drivers/tty/cyclades.c
@@ -45,7 +45,6 @@
 #undef	CY_DEBUG_IO
 #undef	CY_DEBUG_COUNT
 #undef	CY_DEBUG_DTR
-#undef	CY_DEBUG_WAIT_UNTIL_SENT
 #undef	CY_DEBUG_INTERRUPTS
 #undef	CY_16Y_HACK
 #undef	CY_ENABLE_MONITORING
@@ -1678,16 +1677,10 @@ static void cy_wait_until_sent(struct tty_struct *tty, int timeout)
 	 */
 	if (!timeout || timeout > 2 * info->timeout)
 		timeout = 2 * info->timeout;
-#ifdef CY_DEBUG_WAIT_UNTIL_SENT
-	printk(KERN_DEBUG "In cy_wait_until_sent(%d) check=%d, jiff=%lu...",
-		timeout, char_time, jiffies);
-#endif
+
 	card = info->card;
 	if (!cy_is_Z(card)) {
 		while (cyy_readb(info, CySRER) & CyTxRdy) {
-#ifdef CY_DEBUG_WAIT_UNTIL_SENT
-			printk(KERN_DEBUG "Not clean (jiff=%lu)...", jiffies);
-#endif
 			if (msleep_interruptible(jiffies_to_msecs(char_time)))
 				break;
 			if (timeout && time_after(jiffies, orig_jiffies +
@@ -1697,9 +1690,6 @@ static void cy_wait_until_sent(struct tty_struct *tty, int timeout)
 	}
 	/* Run one more char cycle */
 	msleep_interruptible(jiffies_to_msecs(char_time * 5));
-#ifdef CY_DEBUG_WAIT_UNTIL_SENT
-	printk(KERN_DEBUG "Clean (jiff=%lu)...done\n", jiffies);
-#endif
 }
 
 static void cy_flush_buffer(struct tty_struct *tty)
diff --git a/drivers/tty/mxser.c b/drivers/tty/mxser.c
index 7fc8c02..8998d52 100644
--- a/drivers/tty/mxser.c
+++ b/drivers/tty/mxser.c
@@ -2005,16 +2005,9 @@ static void mxser_wait_until_sent(struct tty_struct *tty, int timeout)
 	 */
 	if (!timeout || timeout > 2 * info->timeout)
 		timeout = 2 * info->timeout;
-#ifdef SERIAL_DEBUG_RS_WAIT_UNTIL_SENT
-	printk(KERN_DEBUG "In rs_wait_until_sent(%d) check=%lu...",
-		timeout, char_time);
-	printk("jiff=%lu...", jiffies);
-#endif
+
 	spin_lock_irqsave(&info->slock, flags);
 	while (!((lsr = inb(info->ioaddr + UART_LSR)) & UART_LSR_TEMT)) {
-#ifdef SERIAL_DEBUG_RS_WAIT_UNTIL_SENT
-		printk("lsr = %d (jiff=%lu)...", lsr, jiffies);
-#endif
 		spin_unlock_irqrestore(&info->slock, flags);
 		schedule_timeout_interruptible(char_time);
 		spin_lock_irqsave(&info->slock, flags);
@@ -2025,10 +2018,6 @@ static void mxser_wait_until_sent(struct tty_struct *tty, int timeout)
 	}
 	spin_unlock_irqrestore(&info->slock, flags);
 	set_current_state(TASK_RUNNING);
-
-#ifdef SERIAL_DEBUG_RS_WAIT_UNTIL_SENT
-	printk("lsr = %d (jiff=%lu)...done\n", lsr, jiffies);
-#endif
 }
 
 /*
-- 
1.7.6



^ permalink raw reply related	[flat|nested] 19+ messages in thread

* Re: [PATCH v2 1/6] TTY: serial, remove BTM from wait_until_sent
  2011-07-14 12:35 [PATCH v2 1/6] TTY: serial, remove BTM from wait_until_sent Jiri Slaby
                   ` (4 preceding siblings ...)
  2011-07-14 12:35 ` [PATCH v2 6/6] TTY: mxser+cyclades remove wait_until_sent debug code Jiri Slaby
@ 2011-07-14 13:24 ` Arnd Bergmann
  2011-07-19  0:35 ` Andreas Bombe
  6 siblings, 0 replies; 19+ messages in thread
From: Arnd Bergmann @ 2011-07-14 13:24 UTC (permalink / raw)
  To: Jiri Slaby
  Cc: gregkh, jirislaby, linux-serial, linux-kernel, Alan Cox, Andreas Bombe

On Thursday 14 July 2011, Jiri Slaby wrote:
> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
> References: https://lkml.org/lkml/2011/5/25/562
> Cc: Greg Kroah-Hartman <gregkh@suse.de>
> Cc: Alan Cox <alan@linux.intel.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Andreas Bombe <aeb@debian.org>

Acked-by: Arnd Bergmann <arnd@arndb.de>

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH v2 1/6] TTY: serial, remove BTM from wait_until_sent
  2011-07-14 12:35 [PATCH v2 1/6] TTY: serial, remove BTM from wait_until_sent Jiri Slaby
                   ` (5 preceding siblings ...)
  2011-07-14 13:24 ` [PATCH v2 1/6] TTY: serial, remove BTM from wait_until_sent Arnd Bergmann
@ 2011-07-19  0:35 ` Andreas Bombe
  2011-08-08 13:21   ` Jiri Slaby
  6 siblings, 1 reply; 19+ messages in thread
From: Andreas Bombe @ 2011-07-19  0:35 UTC (permalink / raw)
  To: Jiri Slaby
  Cc: gregkh, jirislaby, linux-serial, linux-kernel, Alan Cox, Arnd Bergmann

On Thu, Jul 14, 2011 at 02:35:10PM +0200, Jiri Slaby wrote:
> This should also fix the issue Andreas is seeing (BTM in comparison to
> BKL doesn't have any hidden functionality like unlocking during
> sleeping).

I tested the patch series and it does not appear to make a difference
for the internal (16550A) serial ports on my system. Also, I am still
unclear on why it freezes the X display during the timeout period.

The other serial port device I have at hand is a FTDI USB->Dual UART
which appears to not have a timeout at all, but then that shows no
difference whether your patches are applied or not. I don't remember if
it was always that way, at least 2.6.39 also acts identically.

-- 
Andreas Bombe

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH v2 3/6] TTY: serial, remove tasklet for tty_wakeup
  2011-07-14 12:35 ` [PATCH v2 3/6] TTY: serial, remove tasklet for tty_wakeup Jiri Slaby
@ 2011-07-19 16:34   ` Alan Cox
  2011-08-31 14:43     ` Jiri Slaby
  0 siblings, 1 reply; 19+ messages in thread
From: Alan Cox @ 2011-07-19 16:34 UTC (permalink / raw)
  To: Jiri Slaby; +Cc: gregkh, jirislaby, linux-serial, linux-kernel

On Thu, 14 Jul 2011 14:35:12 +0200
Jiri Slaby <jslaby@suse.cz> wrote:

> tty_wakeup can be called from any context. So there is no need to have
> an extra tasklet for calling that. Hence save some space and remove
> the tasklet completely.
> 
> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
> Cc: Greg Kroah-Hartman <gregkh@suse.de>
> Cc: Alan Cox <alan@linux.intel.com>
> ---
>  drivers/tty/serial/serial_core.c |   20 +-------------------
>  include/linux/serial_core.h      |    1 -
>  2 files changed, 1 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/tty/serial/serial_core.c
> b/drivers/tty/serial/serial_core.c index 2cbf1bd..4786232 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -72,7 +72,7 @@ void uart_write_wakeup(struct uart_port *port)
>  	 * closed.  No cookie for you.
>  	 */
>  	BUG_ON(!state);
> -	tasklet_schedule(&state->tlet);
> +	tty_wakeup(state->port.tty);

Probably worth noting that this is only safe if the uart locks are held
and because of the current lock/ref drop combinations in the
serial_core code otherwise it can race with hangup...

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH v2 5/6] TTY: remove tty_locked
  2011-07-14 12:35 ` [PATCH v2 5/6] TTY: remove tty_locked Jiri Slaby
@ 2011-07-19 16:35   ` Alan Cox
  0 siblings, 0 replies; 19+ messages in thread
From: Alan Cox @ 2011-07-19 16:35 UTC (permalink / raw)
  To: Jiri Slaby; +Cc: gregkh, jirislaby, linux-serial, linux-kernel

On Thu, 14 Jul 2011 14:35:14 +0200
Jiri Slaby <jslaby@suse.cz> wrote:

> We used it really only serial and ami_serial. The rest of the
> callsites were BUG/WARN_ONs to check if BTM is held. Now that we
> pruned tty_locked from both of the real users, we can get rid of
> tty_lock along with __big_tty_mutex_owner.

All looks sensible to me for this series

(the uart wakeup one isn't new and its a different battle to fight)

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH v2 1/6] TTY: serial, remove BTM from wait_until_sent
  2011-07-19  0:35 ` Andreas Bombe
@ 2011-08-08 13:21   ` Jiri Slaby
  2011-08-10  1:09     ` Andreas Bombe
  0 siblings, 1 reply; 19+ messages in thread
From: Jiri Slaby @ 2011-08-08 13:21 UTC (permalink / raw)
  To: Andreas Bombe
  Cc: Jiri Slaby, gregkh, linux-serial, linux-kernel, Alan Cox, Arnd Bergmann

On 07/19/2011 02:35 AM, Andreas Bombe wrote:
> On Thu, Jul 14, 2011 at 02:35:10PM +0200, Jiri Slaby wrote:
>> This should also fix the issue Andreas is seeing (BTM in comparison to
>> BKL doesn't have any hidden functionality like unlocking during
>> sleeping).
> 
> I tested the patch series and it does not appear to make a difference
> for the internal (16550A) serial ports on my system. Also, I am still
> unclear on why it freezes the X display during the timeout period.

Sorry for the delay. Could you attach output of sysrq-t when this
happens? I mean with a kernel patched by my patch.

thanks,
-- 
js

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH v2 1/6] TTY: serial, remove BTM from wait_until_sent
  2011-08-08 13:21   ` Jiri Slaby
@ 2011-08-10  1:09     ` Andreas Bombe
  2011-08-10  9:46       ` Jiri Slaby
  2011-08-10 14:43       ` Jiri Slaby
  0 siblings, 2 replies; 19+ messages in thread
From: Andreas Bombe @ 2011-08-10  1:09 UTC (permalink / raw)
  To: Jiri Slaby
  Cc: Jiri Slaby, gregkh, linux-serial, linux-kernel, Alan Cox, Arnd Bergmann

[-- Attachment #1: Type: text/plain, Size: 13368 bytes --]

On Mon, Aug 08, 2011 at 03:21:22PM +0200, Jiri Slaby wrote:
> On 07/19/2011 02:35 AM, Andreas Bombe wrote:
> > On Thu, Jul 14, 2011 at 02:35:10PM +0200, Jiri Slaby wrote:
> >> This should also fix the issue Andreas is seeing (BTM in comparison to
> >> BKL doesn't have any hidden functionality like unlocking during
> >> sleeping).
> > 
> > I tested the patch series and it does not appear to make a difference
> > for the internal (16550A) serial ports on my system. Also, I am still
> > unclear on why it freezes the X display during the timeout period.
> 
> Sorry for the delay. Could you attach output of sysrq-t when this
> happens? I mean with a kernel patched by my patch.

I did my simple test on ttyS0 again: "stty -F /dev/ttyS0 crtscts" then
"echo >/dev/ttyS0". I attached the gzipped sysrq-t list in case you need
the complete output. This is just the process while it is trying to
close the device (bash's internal echo):

[  321.948012] bash            S ffff8800bcc85e80     0  4000   2828 0x00000000
[  321.948012]  ffff880127079c38 0000000000000046 ffff880127079c50 0000000100002fff
[  321.948012]  ffff880127079fd8 0000000000011fc0 ffff880127079fd8 0000000000011fc0
[  321.948012]  ffff8801270dde80 ffff8800bcc85e80 ffff880127079c38 0000000100002fff
[  321.948012] Call Trace:
[  321.948012]  [<ffffffff813cdf2e>] schedule_timeout+0xb5/0xf2
[  321.948012]  [<ffffffff8104ae2b>] ? call_timer_fn+0x154/0x154
[  321.948012]  [<ffffffff81255d60>] tty_wait_until_sent+0xa3/0xec
[  321.948012]  [<ffffffff8105a190>] ? __init_waitqueue_head+0x46/0x46
[  321.948012]  [<ffffffff81268c05>] uart_close+0x12b/0x243
[  321.948012]  [<ffffffff81250454>] ? __tty_fasync+0x5c/0x124
[  321.948012]  [<ffffffff81251a00>] tty_release+0x1d3/0x4d7
[  321.948012]  [<ffffffff813cfbd8>] ? _raw_spin_unlock+0x43/0x51
[  321.948012]  [<ffffffff8110db81>] ? dput+0xfe/0x11d
[  321.948012]  [<ffffffff810fdc86>] __fput+0x107/0x1a2
[  321.948012]  [<ffffffff810fdd36>] fput+0x15/0x17
[  321.948012]  [<ffffffff810fb014>] filp_close+0x69/0x75
[  321.948012]  [<ffffffff81109654>] sys_dup3+0x12b/0x153
[  321.948012]  [<ffffffff811096d5>] sys_dup2+0x59/0x60
[  321.948012]  [<ffffffff813d0a12>] system_call_fastpath+0x16/0x1b


[  321.948012] Sched Debug Version: v0.10, 3.1.0-rc1+ser-00011-g37ed45d #87
[  321.948012] ktime                                   : 321967.638593
[  321.948012] sched_clk                               : 321738.307013
[  321.948012] cpu_clk                                 : 321948.012318
[  321.948012] jiffies                                 : 4294972787
[  321.948012] sched_clock_stable                      : 0
[  321.948012] 
[  321.948012] sysctl_sched
[  321.948012]   .sysctl_sched_latency                    : 12.000000
[  321.948012]   .sysctl_sched_min_granularity            : 1.500000
[  321.948012]   .sysctl_sched_wakeup_granularity         : 2.000000
[  321.948012]   .sysctl_sched_child_runs_first           : 0
[  321.948012]   .sysctl_sched_features                   : 15471
[  321.948012]   .sysctl_sched_tunable_scaling            : 1 (logaritmic)
[  321.948012] 
[  321.948012] cpu#0, 3166.466 MHz
[  321.948012]   .nr_running                    : 2
[  321.948012]   .load                          : 1927
[  321.948012]   .nr_switches                   : 181895
[  321.948012]   .nr_load_updates               : 28885
[  321.948012]   .nr_uninterruptible            : 58
[  321.948012]   .next_balance                  : 4294.972819
[  321.948012]   .curr->pid                     : 11
[  321.948012]   .clock                         : 321964.006925
[  321.948012]   .cpu_load[0]                   : 1927
[  321.948012]   .cpu_load[1]                   : 1743
[  321.948012]   .cpu_load[2]                   : 1400
[  321.948012]   .cpu_load[3]                   : 1137
[  321.948012]   .cpu_load[4]                   : 871
[  321.948012]   .yld_count                     : 20444
[  321.948012]   .sched_switch                  : 0
[  321.948012]   .sched_count                   : 203439
[  321.948012]   .sched_goidle                  : 58617
[  321.948012]   .avg_idle                      : 1000000
[  321.948012]   .ttwu_count                    : 112788
[  321.948012]   .ttwu_local                    : 63063
[  321.948012] 
[  321.948012] cfs_rq[0]:/autogroup-58
[  321.948012]   .exec_clock                    : 995.435149
[  321.948012]   .MIN_vruntime                  : 962.061080
[  321.948012]   .min_vruntime                  : 962.061080
[  321.948012]   .max_vruntime                  : 962.061080
[  321.948012]   .spread                        : 0.000000
[  321.948012]   .spread0                       : -22090.643266
[  321.948012]   .nr_spread_over                : 0
[  321.948012]   .nr_running                    : 1
[  321.948012]   .load                          : 1024
[  321.948012]   .load_avg                      : 6435.076254
[  321.948012]   .load_period                   : 6.287393
[  321.948012]   .load_contrib                  : 1004
[  321.948012]   .load_tg                       : 1140
[  321.948012]   .se->exec_start                : 321727.319580
[  321.948012]   .se->vruntime                  : 23059.712463
[  321.948012]   .se->sum_exec_runtime          : 995.837577
[  321.948012]   .se->statistics.wait_start     : 321964.006925
[  321.948012]   .se->statistics.sleep_start    : 0.000000
[  321.948012]   .se->statistics.block_start    : 0.000000
[  321.948012]   .se->statistics.sleep_max      : 0.000000
[  321.948012]   .se->statistics.block_max      : 0.000000
[  321.948012]   .se->statistics.exec_max       : 4.000979
[  321.948012]   .se->statistics.slice_max      : 2.977407
[  321.948012]   .se->statistics.wait_max       : 8.300527
[  321.948012]   .se->statistics.wait_sum       : 309.360276
[  321.948012]   .se->statistics.wait_count     : 8489
[  321.948012]   .se->load.weight               : 903
[  321.948012] 
[  321.948012] cfs_rq[0]:/
[  321.948012]   .exec_clock                    : 20767.422942
[  321.948012]   .MIN_vruntime                  : 23059.712463
[  321.948012]   .min_vruntime                  : 23052.704346
[  321.948012]   .max_vruntime                  : 23059.712463
[  321.948012]   .spread                        : 0.000000
[  321.948012]   .spread0                       : 0.000000
[  321.948012]   .nr_spread_over                : 73
[  321.948012]   .nr_running                    : 2
[  321.948012]   .load                          : 1927
[  321.948012]   .load_avg                      : 0.000000
[  321.948012]   .load_period                   : 0.000000
[  321.948012]   .load_contrib                  : 0
[  321.948012]   .load_tg                       : 0
[  321.948012] 
[  321.948012] rt_rq[0]:
[  321.948012]   .rt_nr_running                 : 0
[  321.948012]   .rt_throttled                  : 0
[  321.948012]   .rt_time                       : 0.000000
[  321.948012]   .rt_runtime                    : 950.000000
[  321.948012] 
[  321.948012] runnable tasks:
[  321.948012]             task   PID         tree-key  switches  prio     exec-runtime         sum-exec        sum-sleep
[  321.948012] ----------------------------------------------------------------------------------------------------------
[  321.948012] R    kworker/0:1    11     23052.704346     13969   120     23052.704346       555.720586    321027.845811 /
[  321.948012]        alsa-sink  3110       962.061080      4307   120       962.061080      1411.254175    258698.264923 /autogroup-58
[  321.948012] 
[  321.948012] cpu#1, 3166.466 MHz
[  321.948012]   .nr_running                    : 0
[  321.948012]   .load                          : 0
[  321.948012]   .nr_switches                   : 206709
[  321.948012]   .nr_load_updates               : 30117
[  321.948012]   .nr_uninterruptible            : -58
[  321.948012]   .next_balance                  : 4294.972776
[  321.948012]   .curr->pid                     : 0
[  321.948012]   .clock                         : 321846.477751
[  321.948012]   .cpu_load[0]                   : 947
[  321.948012]   .cpu_load[1]                   : 481
[  321.948012]   .cpu_load[2]                   : 282
[  321.948012]   .cpu_load[3]                   : 183
[  321.948012]   .cpu_load[4]                   : 133
[  321.948012]   .yld_count                     : 26864
[  321.948012]   .sched_switch                  : 0
[  321.948012]   .sched_count                   : 233886
[  321.948012]   .sched_goidle                  : 75296
[  321.948012]   .avg_idle                      : 1000000
[  321.948012]   .ttwu_count                    : 96142
[  321.948012]   .ttwu_local                    : 60872
[  321.948012] 
[  321.948012] cfs_rq[1]:/autogroup-58
[  321.948012]   .exec_clock                    : 1096.255751
[  321.948012]   .MIN_vruntime                  : 0.000001
[  321.948012]   .min_vruntime                  : 1043.264049
[  321.948012]   .max_vruntime                  : 0.000001
[  321.948012]   .spread                        : 0.000000
[  321.948012]   .spread0                       : -22009.440297
[  321.948012]   .nr_spread_over                : 0
[  321.948012]   .nr_running                    : 0
[  321.948012]   .load                          : 0
[  321.948012]   .load_avg                      : 894.748356
[  321.948012]   .load_period                   : 6.572338
[  321.948012]   .load_contrib                  : 136
[  321.948012]   .load_tg                       : 1140
[  321.948012]   .se->exec_start                : 321808.596733
[  321.948012]   .se->vruntime                  : 20943.081256
[  321.948012]   .se->sum_exec_runtime          : 1096.712219
[  321.948012]   .se->statistics.wait_start     : 0.000000
[  321.948012]   .se->statistics.sleep_start    : 0.000000
[  321.948012]   .se->statistics.block_start    : 0.000000
[  321.948012]   .se->statistics.sleep_max      : 0.000000
[  321.948012]   .se->statistics.block_max      : 0.000000
[  321.948012]   .se->statistics.exec_max       : 4.042092
[  321.948012]   .se->statistics.slice_max      : 1.274462
[  321.948012]   .se->statistics.wait_max       : 11.013496
[  321.948012]   .se->statistics.wait_sum       : 303.941198
[  321.948012]   .se->statistics.wait_count     : 8528
[  321.948012]   .se->load.weight               : 2
[  321.948012] 
[  321.948012] cfs_rq[1]:/autogroup-53
[  321.948012]   .exec_clock                    : 5152.934351
[  321.948012]   .MIN_vruntime                  : 0.000001
[  321.948012]   .min_vruntime                  : 10693.441896
[  321.948012]   .max_vruntime                  : 0.000001
[  321.948012]   .spread                        : 0.000000
[  321.948012]   .spread0                       : -12359.262450
[  321.948012]   .nr_spread_over                : 81
[  321.948012]   .nr_running                    : 0
[  321.948012]   .load                          : 0
[  321.948012]   .load_avg                      : 124.928296
[  321.948012]   .load_period                   : 6.455088
[  321.948012]   .load_contrib                  : 19
[  321.948012]   .load_tg                       : 19
[  321.948012]   .se->exec_start                : 321807.916228
[  321.948012]   .se->vruntime                  : 20936.418846
[  321.948012]   .se->sum_exec_runtime          : 5153.129023
[  321.948012]   .se->statistics.wait_start     : 0.000000
[  321.948012]   .se->statistics.sleep_start    : 0.000000
[  321.948012]   .se->statistics.block_start    : 0.000000
[  321.948012]   .se->statistics.sleep_max      : 0.000000
[  321.948012]   .se->statistics.block_max      : 0.000000
[  321.948012]   .se->statistics.exec_max       : 4.032091
[  321.948012]   .se->statistics.slice_max      : 7.996020
[  321.948012]   .se->statistics.wait_max       : 32.784820
[  321.948012]   .se->statistics.wait_sum       : 839.992046
[  321.948012]   .se->statistics.wait_count     : 55429
[  321.948012]   .se->load.weight               : 2
[  321.948012] 
[  321.948012] cfs_rq[1]:/
[  321.948012]   .exec_clock                    : 18512.679083
[  321.948012]   .MIN_vruntime                  : 0.000001
[  321.948012]   .min_vruntime                  : 20943.081256
[  321.948012]   .max_vruntime                  : 0.000001
[  321.948012]   .spread                        : 0.000000
[  321.948012]   .spread0                       : -2109.623090
[  321.948012]   .nr_spread_over                : 91
[  321.948012]   .nr_running                    : 0
[  321.948012]   .load                          : 0
[  321.948012]   .load_avg                      : 0.000000
[  321.948012]   .load_period                   : 0.000000
[  321.948012]   .load_contrib                  : 0
[  321.948012]   .load_tg                       : 0
[  321.948012] 
[  321.948012] rt_rq[1]:
[  321.948012]   .rt_nr_running                 : 0
[  321.948012]   .rt_throttled                  : 0
[  321.948012]   .rt_time                       : 0.000000
[  321.948012]   .rt_runtime                    : 950.000000
[  321.948012] 
[  321.948012] runnable tasks:
[  321.948012]             task   PID         tree-key  switches  prio     exec-runtime         sum-exec        sum-sleep
[  321.948012] ----------------------------------------------------------------------------------------------------------
[  321.948012] 
[  321.948012] INFO: lockdep is turned off.

-- 
Andreas Bombe

[-- Attachment #2: dmesg.sysrqt-complete.gz --]
[-- Type: application/octet-stream, Size: 29828 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH v2 1/6] TTY: serial, remove BTM from wait_until_sent
  2011-08-10  1:09     ` Andreas Bombe
@ 2011-08-10  9:46       ` Jiri Slaby
  2011-08-10 12:25         ` Andreas Bombe
  2011-08-10 14:43       ` Jiri Slaby
  1 sibling, 1 reply; 19+ messages in thread
From: Jiri Slaby @ 2011-08-10  9:46 UTC (permalink / raw)
  To: Andreas Bombe
  Cc: Jiri Slaby, gregkh, linux-serial, linux-kernel, Alan Cox, Arnd Bergmann

On 08/10/2011 03:09 AM, Andreas Bombe wrote:
> On Mon, Aug 08, 2011 at 03:21:22PM +0200, Jiri Slaby wrote:
>> On 07/19/2011 02:35 AM, Andreas Bombe wrote:
>>> On Thu, Jul 14, 2011 at 02:35:10PM +0200, Jiri Slaby wrote:
>>>> This should also fix the issue Andreas is seeing (BTM in comparison to
>>>> BKL doesn't have any hidden functionality like unlocking during
>>>> sleeping).
>>>
>>> I tested the patch series and it does not appear to make a difference
>>> for the internal (16550A) serial ports on my system. Also, I am still
>>> unclear on why it freezes the X display during the timeout period.
>>
>> Sorry for the delay. Could you attach output of sysrq-t when this
>> happens? I mean with a kernel patched by my patch.
> 
> I did my simple test on ttyS0 again: "stty -F /dev/ttyS0 crtscts" then
> "echo >/dev/ttyS0". I attached the gzipped sysrq-t list in case you need
> the complete output. This is just the process while it is trying to
> close the device (bash's internal echo):
> 
> [  321.948012] bash            S ffff8800bcc85e80     0  4000   2828 0x00000000
> [  321.948012]  ffff880127079c38 0000000000000046 ffff880127079c50 0000000100002fff
> [  321.948012]  ffff880127079fd8 0000000000011fc0 ffff880127079fd8 0000000000011fc0
> [  321.948012]  ffff8801270dde80 ffff8800bcc85e80 ffff880127079c38 0000000100002fff
> [  321.948012] Call Trace:
> [  321.948012]  [<ffffffff813cdf2e>] schedule_timeout+0xb5/0xf2
> [  321.948012]  [<ffffffff8104ae2b>] ? call_timer_fn+0x154/0x154
> [  321.948012]  [<ffffffff81255d60>] tty_wait_until_sent+0xa3/0xec
> [  321.948012]  [<ffffffff8105a190>] ? __init_waitqueue_head+0x46/0x46
> [  321.948012]  [<ffffffff81268c05>] uart_close+0x12b/0x243
> [  321.948012]  [<ffffffff81250454>] ? __tty_fasync+0x5c/0x124
> [  321.948012]  [<ffffffff81251a00>] tty_release+0x1d3/0x4d7
> [  321.948012]  [<ffffffff813cfbd8>] ? _raw_spin_unlock+0x43/0x51
> [  321.948012]  [<ffffffff8110db81>] ? dput+0xfe/0x11d
> [  321.948012]  [<ffffffff810fdc86>] __fput+0x107/0x1a2
> [  321.948012]  [<ffffffff810fdd36>] fput+0x15/0x17
> [  321.948012]  [<ffffffff810fb014>] filp_close+0x69/0x75
> [  321.948012]  [<ffffffff81109654>] sys_dup3+0x12b/0x153
> [  321.948012]  [<ffffffff811096d5>] sys_dup2+0x59/0x60
> [  321.948012]  [<ffffffff813d0a12>] system_call_fastpath+0x16/0x1b
> 
> 
> [  321.948012] Sched Debug Version: v0.10, 3.1.0-rc1+ser-00011-g37ed45d #87

What tree is this? I cannot see the path through the code.

thanks,
-- 
js
suse labs

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH v2 1/6] TTY: serial, remove BTM from wait_until_sent
  2011-08-10  9:46       ` Jiri Slaby
@ 2011-08-10 12:25         ` Andreas Bombe
  0 siblings, 0 replies; 19+ messages in thread
From: Andreas Bombe @ 2011-08-10 12:25 UTC (permalink / raw)
  To: Jiri Slaby
  Cc: Jiri Slaby, gregkh, linux-serial, linux-kernel, Alan Cox, Arnd Bergmann

On Wed, Aug 10, 2011 at 11:46:44AM +0200, Jiri Slaby wrote:
> > [  321.948012] Sched Debug Version: v0.10, 3.1.0-rc1+ser-00011-g37ed45d #87
> 
> What tree is this? I cannot see the path through the code.

In order to identify patched versions, I inserted a commit to add "+ser"
to EXTRAVERSION before applying your patch series. Otherwise it's just
the plain Linux git from Linus. I just rebased onto the latest git
for the new test but I can't say which version exactly because I don't
have that tree with me right now.

-- 
Andreas Bombe

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH v2 1/6] TTY: serial, remove BTM from wait_until_sent
  2011-08-10  1:09     ` Andreas Bombe
  2011-08-10  9:46       ` Jiri Slaby
@ 2011-08-10 14:43       ` Jiri Slaby
  2011-08-10 18:07         ` Andreas Bombe
  1 sibling, 1 reply; 19+ messages in thread
From: Jiri Slaby @ 2011-08-10 14:43 UTC (permalink / raw)
  To: Andreas Bombe
  Cc: Jiri Slaby, gregkh, linux-serial, linux-kernel, Alan Cox, Arnd Bergmann

On 08/10/2011 03:09 AM, Andreas Bombe wrote:
> On Mon, Aug 08, 2011 at 03:21:22PM +0200, Jiri Slaby wrote:
>> On 07/19/2011 02:35 AM, Andreas Bombe wrote:
>>> On Thu, Jul 14, 2011 at 02:35:10PM +0200, Jiri Slaby wrote:
>>>> This should also fix the issue Andreas is seeing (BTM in comparison to
>>>> BKL doesn't have any hidden functionality like unlocking during
>>>> sleeping).
>>>
>>> I tested the patch series and it does not appear to make a difference
>>> for the internal (16550A) serial ports on my system. Also, I am still
>>> unclear on why it freezes the X display during the timeout period.
>>
>> Sorry for the delay. Could you attach output of sysrq-t when this
>> happens? I mean with a kernel patched by my patch.
> 
> I did my simple test on ttyS0 again: "stty -F /dev/ttyS0 crtscts" then
> "echo >/dev/ttyS0". I attached the gzipped sysrq-t list in case you need
> the complete output. This is just the process while it is trying to
> close the device (bash's internal echo):

Hmm, perhaps obvious question. What is the port connected with? And with
what cable? Is it null modem cable? Or at least with DTR-CTS connected?

thanks,
-- 
js

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH v2 1/6] TTY: serial, remove BTM from wait_until_sent
  2011-08-10 14:43       ` Jiri Slaby
@ 2011-08-10 18:07         ` Andreas Bombe
  2011-08-10 18:10           ` Jiri Slaby
  0 siblings, 1 reply; 19+ messages in thread
From: Andreas Bombe @ 2011-08-10 18:07 UTC (permalink / raw)
  To: Jiri Slaby
  Cc: Jiri Slaby, gregkh, linux-serial, linux-kernel, Alan Cox, Arnd Bergmann

On Wed, Aug 10, 2011 at 04:43:19PM +0200, Jiri Slaby wrote:
> On 08/10/2011 03:09 AM, Andreas Bombe wrote:
> > I did my simple test on ttyS0 again: "stty -F /dev/ttyS0 crtscts" then
> > "echo >/dev/ttyS0". I attached the gzipped sysrq-t list in case you need
> > the complete output. This is just the process while it is trying to
> > close the device (bash's internal echo):
> 
> Hmm, perhaps obvious question. What is the port connected with? And with
> what cable? Is it null modem cable? Or at least with DTR-CTS connected?

Nothing is connected. After all, the whole point of this exercise is to
give the driver data to send which it can't get out so I can see whether
it blocks all tty operations system wide while trying to do the flush on
close.

-- 
Andreas Bombe

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH v2 1/6] TTY: serial, remove BTM from wait_until_sent
  2011-08-10 18:07         ` Andreas Bombe
@ 2011-08-10 18:10           ` Jiri Slaby
  2011-08-11  1:06             ` Andreas Bombe
  0 siblings, 1 reply; 19+ messages in thread
From: Jiri Slaby @ 2011-08-10 18:10 UTC (permalink / raw)
  To: Jiri Slaby, gregkh, linux-serial, linux-kernel, Alan Cox, Arnd Bergmann

On 08/10/2011 08:07 PM, Andreas Bombe wrote:
> On Wed, Aug 10, 2011 at 04:43:19PM +0200, Jiri Slaby wrote:
>> On 08/10/2011 03:09 AM, Andreas Bombe wrote:
>>> I did my simple test on ttyS0 again: "stty -F /dev/ttyS0 crtscts" then
>>> "echo >/dev/ttyS0". I attached the gzipped sysrq-t list in case you need
>>> the complete output. This is just the process while it is trying to
>>> close the device (bash's internal echo):
>>
>> Hmm, perhaps obvious question. What is the port connected with? And with
>> what cable? Is it null modem cable? Or at least with DTR-CTS connected?
> 
> Nothing is connected. After all, the whole point of this exercise is to
> give the driver data to send which it can't get out so I can see whether
> it blocks all tty operations system wide while trying to do the flush on
> close.

But according to the trace, it waits only in its queue...

Well, could you turn on lockdep and dump sysrq-d when your echo is
closing the port?

thanks,
-- 
js

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH v2 1/6] TTY: serial, remove BTM from wait_until_sent
  2011-08-10 18:10           ` Jiri Slaby
@ 2011-08-11  1:06             ` Andreas Bombe
  0 siblings, 0 replies; 19+ messages in thread
From: Andreas Bombe @ 2011-08-11  1:06 UTC (permalink / raw)
  To: Jiri Slaby
  Cc: Jiri Slaby, gregkh, linux-serial, linux-kernel, Alan Cox, Arnd Bergmann

On Wed, Aug 10, 2011 at 08:10:32PM +0200, Jiri Slaby wrote:
> On 08/10/2011 08:07 PM, Andreas Bombe wrote:
> > On Wed, Aug 10, 2011 at 04:43:19PM +0200, Jiri Slaby wrote:
> >> On 08/10/2011 03:09 AM, Andreas Bombe wrote:
> >>> I did my simple test on ttyS0 again: "stty -F /dev/ttyS0 crtscts" then
> >>> "echo >/dev/ttyS0". I attached the gzipped sysrq-t list in case you need
> >>> the complete output. This is just the process while it is trying to
> >>> close the device (bash's internal echo):
> >>
> >> Hmm, perhaps obvious question. What is the port connected with? And with
> >> what cable? Is it null modem cable? Or at least with DTR-CTS connected?
> > 
> > Nothing is connected. After all, the whole point of this exercise is to
> > give the driver data to send which it can't get out so I can see whether
> > it blocks all tty operations system wide while trying to do the flush on
> > close.
> 
> But according to the trace, it waits only in its queue...
> 
> Well, could you turn on lockdep and dump sysrq-d when your echo is
> closing the port?

Ok, it still appears to be holding the big_tty_mutex. I ran /bin/echo so
that it actually shows up as "echo" here:

[  962.365574] SysRq : Show Locks Held
[  962.365580] 
[  962.365581] Showing all locks held in the system:
[  962.365599] 1 lock held by Xorg/1881:
[  962.365601]  #0:  (big_tty_mutex){+.+.+.}, at: [<ffffffff813d0013>] tty_lock+0x12/0x14
[  962.365624] 1 lock held by getty/2732:
[  962.365626]  #0:  (&tty->atomic_read_lock){+.+.+.}, at: [<ffffffff81254fff>] n_tty_read+0x188/0x681
[  962.365637] 1 lock held by getty/2733:
[  962.365639]  #0:  (&tty->atomic_read_lock){+.+.+.}, at: [<ffffffff81254fff>] n_tty_read+0x188/0x681
[  962.365647] 1 lock held by getty/2734:
[  962.365649]  #0:  (&tty->atomic_read_lock){+.+.+.}, at: [<ffffffff81254fff>] n_tty_read+0x188/0x681
[  962.365658] 1 lock held by getty/2735:
[  962.365660]  #0:  (&tty->atomic_read_lock){+.+.+.}, at: [<ffffffff81254fff>] n_tty_read+0x188/0x681
[  962.365679] 1 lock held by bash/2994:
[  962.365681]  #0:  (&tty->atomic_read_lock){+.+.+.}, at: [<ffffffff81254fff>] n_tty_read+0x188/0x681
[  962.365691] 1 lock held by bash/3326:
[  962.365692]  #0:  (&tty->atomic_read_lock){+.+.+.}, at: [<ffffffff81254fff>] n_tty_read+0x188/0x681
[  962.365701] 1 lock held by bash/3444:
[  962.365703]  #0:  (&tty->atomic_read_lock){+.+.+.}, at: [<ffffffff81254fff>] n_tty_read+0x188/0x681
[  962.365713] 1 lock held by bash/3793:
[  962.365715]  #0:  (&tty->atomic_read_lock){+.+.+.}, at: [<ffffffff81254fff>] n_tty_read+0x188/0x681
[  962.365725] 1 lock held by less/3899:
[  962.365727]  #0:  (&tty->atomic_read_lock){+.+.+.}, at: [<ffffffff81254fff>] n_tty_read+0x188/0x681
[  962.365735] 2 locks held by echo/4162:
[  962.365737]  #0:  (big_tty_mutex){+.+.+.}, at: [<ffffffff813d0013>] tty_lock+0x12/0x14
[  962.365746]  #1:  (&port->mutex){+.+.+.}, at: [<ffffffff81268b46>] uart_close+0x6c/0x243
[  962.365754] 
[  962.365756] =============================================
[  962.365757] 


Also, can you not reproduce it? I thought the "enable hardware handshake
on unconnected port and send" dance should be universal enough to work
for everyone. Everyone with a serial port somewhere in the system, that
is.

-- 
Andreas Bombe

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH v2 3/6] TTY: serial, remove tasklet for tty_wakeup
  2011-07-19 16:34   ` Alan Cox
@ 2011-08-31 14:43     ` Jiri Slaby
  0 siblings, 0 replies; 19+ messages in thread
From: Jiri Slaby @ 2011-08-31 14:43 UTC (permalink / raw)
  To: Alan Cox; +Cc: Jiri Slaby, gregkh, linux-serial, linux-kernel

On 07/19/2011 06:34 PM, Alan Cox wrote:
> On Thu, 14 Jul 2011 14:35:12 +0200
> Jiri Slaby <jslaby@suse.cz> wrote:
> 
>> tty_wakeup can be called from any context. So there is no need to have
>> an extra tasklet for calling that. Hence save some space and remove
>> the tasklet completely.
>>
>> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
>> Cc: Greg Kroah-Hartman <gregkh@suse.de>
>> Cc: Alan Cox <alan@linux.intel.com>
>> ---
>>  drivers/tty/serial/serial_core.c |   20 +-------------------
>>  include/linux/serial_core.h      |    1 -
>>  2 files changed, 1 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/tty/serial/serial_core.c
>> b/drivers/tty/serial/serial_core.c index 2cbf1bd..4786232 100644
>> --- a/drivers/tty/serial/serial_core.c
>> +++ b/drivers/tty/serial/serial_core.c
>> @@ -72,7 +72,7 @@ void uart_write_wakeup(struct uart_port *port)
>>  	 * closed.  No cookie for you.
>>  	 */
>>  	BUG_ON(!state);
>> -	tasklet_schedule(&state->tlet);
>> +	tty_wakeup(state->port.tty);
> 
> Probably worth noting that this is only safe if the uart locks are held
> and because of the current lock/ref drop combinations in the
> serial_core code otherwise it can race with hangup...

I see this was merged. Since I was not sure this patch is OK after your
comment, I reviewed the code now. It shouldn't be an issue right now,
exactly as you wrote. I.e. the device is stopped, ISR synchronized and
even then ->hangup sets tty to NULL.

I have a patch in my queue which converts all these guys to
tty_port_tty_get. This is needed before I can use tty_port_hangup
obviously. It is because the order there is opposite (set tty to NULL,
then shutdown everybody).

thanks for review,
-- 
js

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2011-08-31 14:43 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-14 12:35 [PATCH v2 1/6] TTY: serial, remove BTM from wait_until_sent Jiri Slaby
2011-07-14 12:35 ` [PATCH v2 2/6] TTY: msm_serial, remove unneeded console set Jiri Slaby
2011-07-14 12:35 ` [PATCH v2 3/6] TTY: serial, remove tasklet for tty_wakeup Jiri Slaby
2011-07-19 16:34   ` Alan Cox
2011-08-31 14:43     ` Jiri Slaby
2011-07-14 12:35 ` [PATCH v2 4/6] TTY: ami_serial, remove BTM from wait_until_sent Jiri Slaby
2011-07-14 12:35 ` [PATCH v2 5/6] TTY: remove tty_locked Jiri Slaby
2011-07-19 16:35   ` Alan Cox
2011-07-14 12:35 ` [PATCH v2 6/6] TTY: mxser+cyclades remove wait_until_sent debug code Jiri Slaby
2011-07-14 13:24 ` [PATCH v2 1/6] TTY: serial, remove BTM from wait_until_sent Arnd Bergmann
2011-07-19  0:35 ` Andreas Bombe
2011-08-08 13:21   ` Jiri Slaby
2011-08-10  1:09     ` Andreas Bombe
2011-08-10  9:46       ` Jiri Slaby
2011-08-10 12:25         ` Andreas Bombe
2011-08-10 14:43       ` Jiri Slaby
2011-08-10 18:07         ` Andreas Bombe
2011-08-10 18:10           ` Jiri Slaby
2011-08-11  1:06             ` Andreas Bombe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).