| Message ID | 87h9ol2r4y.fsf@linutronix.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 07/30/2015 06:54 PM, John Ogness wrote: > uart_write_wakeup() should be called without holding the port lock. > Otherwise a possible recursive spinlock issue can occur, such as > the following callchain: > > 8250_core.c:serial8250_tx_chars() - called with port locked > serial_core.c:uart_write_wakeup() > tty_io.c:tty_wakeup() > st_core.c:st_tty_wakeup() > st_core.c:st_tx_wakeup() > st_core.c:st_int_write() > serial_core.c:uart_write() - locks port NAK. This is a bug in the N_TI_WL line discipline, specifically in the st_tx_wakeup() function, which cannot perform the write synchronously. This is a common line discipline bug, and typically fixed by performing the wakeup operations from a kworker instead. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/30/2015 07:15 PM, Peter Hurley wrote: > On 07/30/2015 06:54 PM, John Ogness wrote: >> uart_write_wakeup() should be called without holding the port lock. >> Otherwise a possible recursive spinlock issue can occur, such as >> the following callchain: >> >> 8250_core.c:serial8250_tx_chars() - called with port locked >> serial_core.c:uart_write_wakeup() >> tty_io.c:tty_wakeup() >> st_core.c:st_tty_wakeup() >> st_core.c:st_tx_wakeup() >> st_core.c:st_int_write() >> serial_core.c:uart_write() - locks port > > NAK. > > This is a bug in the N_TI_WL line discipline, specifically in the > st_tx_wakeup() function, which cannot perform the write synchronously. > > This is a common line discipline bug, and typically fixed by performing > the wakeup operations from a kworker instead. Also, seriously consider if you want to use that TI line discipline at all. If you're using it only for bluetooth w/ kernel bluetooth stack, you don't need btwilink + st_drv anyway. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c index 37fff12..5ac2425 100644 --- a/drivers/tty/serial/8250/8250_core.c +++ b/drivers/tty/serial/8250/8250_core.c @@ -1559,8 +1559,12 @@ void serial8250_tx_chars(struct uart_8250_port *up) } } while (--count > 0); - if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) + if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) { + /* do not hold lock for call to uart_write_wakeup() */ + spin_unlock(&port->lock); uart_write_wakeup(port); + spin_lock(&port->lock); + } DEBUG_INTR("THRE..."); diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c index d75a66c..5b39892 100644 --- a/drivers/tty/serial/8250/8250_omap.c +++ b/drivers/tty/serial/8250/8250_omap.c @@ -861,8 +861,12 @@ static void omap_8250_dma_tx_complete(void *param) omap8250_restore_regs(p); } - if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) + if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) { + /* do not hold lock for call to uart_write_wakeup() */ + spin_unlock(&p->port.lock); uart_write_wakeup(&p->port); + spin_lock(&p->port.lock); + } if (!uart_circ_empty(xmit) && !uart_tx_stopped(&p->port)) { int ret;
uart_write_wakeup() should be called without holding the port lock. Otherwise a possible recursive spinlock issue can occur, such as the following callchain: 8250_core.c:serial8250_tx_chars() - called with port locked serial_core.c:uart_write_wakeup() tty_io.c:tty_wakeup() st_core.c:st_tty_wakeup() st_core.c:st_tx_wakeup() st_core.c:st_int_write() serial_core.c:uart_write() - locks port Signed-off-by: John Ogness <john.ogness@linutronix.de> --- drivers/tty/serial/8250/8250_core.c | 6 +++++- drivers/tty/serial/8250/8250_omap.c | 6 +++++- 2 files changed, 10 insertions(+), 2 deletions(-)