From: Jiri Slaby <jslaby@suse.cz>
To: Andreas Bombe <aeb@debian.org>
Cc: alan@lxorguk.ukuu.org.uk, linux-kernel@vger.kernel.org,
greg@kroah.com, arnd@arndb.de, jirislaby@gmail.com
Subject: Re: tty_lock held during transmit wait in close: still unresolved
Date: Fri, 27 May 2011 14:11:45 +0200 [thread overview]
Message-ID: <1306498305-5486-1-git-send-email-jslaby@suse.cz> (raw)
In-Reply-To: <20110527004104.GB4369@amos.fritz.box>
> > At any point you can show the code sleeps you can drop and retake the
> > tty mutex either side of it, so you should be able to do that in the
> > close timeout case. You may need to think about the order of locking with
> > the port mutex but I suspect you can drop and retake both there.
>
> #basically emulating the BKL semantics? Sounds more doable. I'll look
> into it.
Actually the best would be to get rid of tty_lock completely. Here I
have a patch removing tty_lock from wait_until_sent path. I've been
using a kernel with the patch applied for about month without any
problems. But I have only 8250-based serial.
Why I ahven't sent it is that I need to re-investigate users whether
this will hurt. (I already did, but stopped in the middle to do other
things.) Mostly wait_until_sent hooks in uart drivers do simple reads
from device.
The patch is only the first step. When this patch is OK and works, we
can move the whole uart thing to use tty_port_open/close helpers.
Does the patch below fix the issue?
---
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.4.2
next prev parent reply other threads:[~2011-05-27 12:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-25 23:59 Andreas Bombe
2011-05-26 7:11 ` Greg KH
2011-05-27 0:29 ` Andreas Bombe
2011-05-26 8:17 ` Alan Cox
2011-05-27 0:41 ` Andreas Bombe
2011-05-27 11:38 ` Arnd Bergmann
2011-05-27 12:11 ` Jiri Slaby [this message]
2011-05-27 13:53 ` Arnd Bergmann
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=1306498305-5486-1-git-send-email-jslaby@suse.cz \
--to=jslaby@suse.cz \
--cc=aeb@debian.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arnd@arndb.de \
--cc=greg@kroah.com \
--cc=jirislaby@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®