* [PATCH RFC] tty_ldisc: add more limits to the @write_wakeup
@ 2013-11-13 7:30 Huang Shijie
2013-12-06 10:34 ` Huang Shijie
0 siblings, 1 reply; 5+ messages in thread
From: Huang Shijie @ 2013-11-13 7:30 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: linux-serial-u79uwXL29TY76Z2rM5mHXA,
marcel-kz+m5ild9QBg9hUCZPvPmw,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA, Huang Shijie
In the uart_handle_cts_change(), uart_write_wakeup() is called after
we call @uart_port->ops->start_tx().
The Documentation/serial/driver tells us:
-----------------------------------------------
start_tx(port)
Start transmitting characters.
Locking: port->lock taken.
Interrupts: locally disabled.
-----------------------------------------------
So when the uart_write_wakeup() is called, the port->lock is taken by
the upper. See the following callstack:
|_ uart_write_wakeup
|_ tty_wakeup
|_ ld->ops->write_wakeup
With the port->lock held, we call the @write_wakeup. Some implemetation of
the @write_wakeup does not notice that the port->lock is held, and it still
tries to send data with uart_write() which will try to grab the prot->lock.
A dead lock occurs, see the following log caught in the Bluetooth by uart:
--------------------------------------------------------------------
BUG: spinlock lockup suspected on CPU#0, swapper/0/0
lock: 0xdc3f4410, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.10.17-16839-ge4a1bef #1320
[<80014cbc>] (unwind_backtrace+0x0/0x138) from [<8001251c>] (show_stack+0x10/0x14)
[<8001251c>] (show_stack+0x10/0x14) from [<802816ac>] (do_raw_spin_lock+0x108/0x184)
[<802816ac>] (do_raw_spin_lock+0x108/0x184) from [<806a22b0>] (_raw_spin_lock_irqsave+0x54/0x60)
[<806a22b0>] (_raw_spin_lock_irqsave+0x54/0x60) from [<802f5754>] (uart_write+0x38/0xe0)
[<802f5754>] (uart_write+0x38/0xe0) from [<80455270>] (hci_uart_tx_wakeup+0xa4/0x168)
[<80455270>] (hci_uart_tx_wakeup+0xa4/0x168) from [<802dab18>] (tty_wakeup+0x50/0x5c)
[<802dab18>] (tty_wakeup+0x50/0x5c) from [<802f81a4>] (imx_rtsint+0x50/0x80)
[<802f81a4>] (imx_rtsint+0x50/0x80) from [<802f88f4>] (imx_int+0x158/0x17c)
[<802f88f4>] (imx_int+0x158/0x17c) from [<8007abe0>] (handle_irq_event_percpu+0x50/0x194)
[<8007abe0>] (handle_irq_event_percpu+0x50/0x194) from [<8007ad60>] (handle_irq_event+0x3c/0x5c)
--------------------------------------------------------------------
This patch adds more limits to the @write_wakeup, the one who wants to
implemet the @write_wakeup should follow the limits which avoid the deadlock.
Signed-off-by: Huang Shijie <b32955-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
include/linux/tty_ldisc.h | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/include/linux/tty_ldisc.h b/include/linux/tty_ldisc.h
index f15c898..539ccc5 100644
--- a/include/linux/tty_ldisc.h
+++ b/include/linux/tty_ldisc.h
@@ -91,7 +91,10 @@
* This function is called by the low-level tty driver to signal
* that line discpline should try to send more characters to the
* low-level driver for transmission. If the line discpline does
- * not have any more data to send, it can just return.
+ * not have any more data to send, it can just return. If the line
+ * discipline does have some data to send, please arise a tasklet
+ * or workqueue to do the real data transfer. Do not send data in
+ * this hook, it may leads to a deadlock.
*
* int (*hangup)(struct tty_struct *)
*
--
1.7.2.rc3
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH RFC] tty_ldisc: add more limits to the @write_wakeup
2013-11-13 7:30 [PATCH RFC] tty_ldisc: add more limits to the @write_wakeup Huang Shijie
@ 2013-12-06 10:34 ` Huang Shijie
2013-12-06 16:18 ` Peter Hurley
0 siblings, 1 reply; 5+ messages in thread
From: Huang Shijie @ 2013-12-06 10:34 UTC (permalink / raw)
To: Huang Shijie; +Cc: gregkh, linux-serial, marcel, linux-bluetooth
于 2013年11月13日 15:30, Huang Shijie 写道:
> In the uart_handle_cts_change(), uart_write_wakeup() is called after
> we call @uart_port->ops->start_tx().
>
> The Documentation/serial/driver tells us:
> -----------------------------------------------
> start_tx(port)
> Start transmitting characters.
>
> Locking: port->lock taken.
> Interrupts: locally disabled.
> -----------------------------------------------
>
> So when the uart_write_wakeup() is called, the port->lock is taken by
> the upper. See the following callstack:
>
> |_ uart_write_wakeup
> |_ tty_wakeup
> |_ ld->ops->write_wakeup
>
> With the port->lock held, we call the @write_wakeup. Some implemetation of
> the @write_wakeup does not notice that the port->lock is held, and it still
> tries to send data with uart_write() which will try to grab the prot->lock.
> A dead lock occurs, see the following log caught in the Bluetooth by uart:
>
> --------------------------------------------------------------------
> BUG: spinlock lockup suspected on CPU#0, swapper/0/0
> lock: 0xdc3f4410, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0
> CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.10.17-16839-ge4a1bef #1320
> [<80014cbc>] (unwind_backtrace+0x0/0x138) from [<8001251c>] (show_stack+0x10/0x14)
> [<8001251c>] (show_stack+0x10/0x14) from [<802816ac>] (do_raw_spin_lock+0x108/0x184)
> [<802816ac>] (do_raw_spin_lock+0x108/0x184) from [<806a22b0>] (_raw_spin_lock_irqsave+0x54/0x60)
> [<806a22b0>] (_raw_spin_lock_irqsave+0x54/0x60) from [<802f5754>] (uart_write+0x38/0xe0)
> [<802f5754>] (uart_write+0x38/0xe0) from [<80455270>] (hci_uart_tx_wakeup+0xa4/0x168)
> [<80455270>] (hci_uart_tx_wakeup+0xa4/0x168) from [<802dab18>] (tty_wakeup+0x50/0x5c)
> [<802dab18>] (tty_wakeup+0x50/0x5c) from [<802f81a4>] (imx_rtsint+0x50/0x80)
> [<802f81a4>] (imx_rtsint+0x50/0x80) from [<802f88f4>] (imx_int+0x158/0x17c)
> [<802f88f4>] (imx_int+0x158/0x17c) from [<8007abe0>] (handle_irq_event_percpu+0x50/0x194)
> [<8007abe0>] (handle_irq_event_percpu+0x50/0x194) from [<8007ad60>] (handle_irq_event+0x3c/0x5c)
> --------------------------------------------------------------------
>
> This patch adds more limits to the @write_wakeup, the one who wants to
> implemet the @write_wakeup should follow the limits which avoid the deadlock.
>
> Signed-off-by: Huang Shijie <b32955@freescale.com>
> ---
> include/linux/tty_ldisc.h | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/tty_ldisc.h b/include/linux/tty_ldisc.h
> index f15c898..539ccc5 100644
> --- a/include/linux/tty_ldisc.h
> +++ b/include/linux/tty_ldisc.h
> @@ -91,7 +91,10 @@
> * This function is called by the low-level tty driver to signal
> * that line discpline should try to send more characters to the
> * low-level driver for transmission. If the line discpline does
> - * not have any more data to send, it can just return.
> + * not have any more data to send, it can just return. If the line
> + * discipline does have some data to send, please arise a tasklet
> + * or workqueue to do the real data transfer. Do not send data in
> + * this hook, it may leads to a deadlock.
> *
> * int (*hangup)(struct tty_struct *)
> *
just a ping.
In actually, this is a BUG in the tty code or BT code.
thanks
Huang Shijie
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH RFC] tty_ldisc: add more limits to the @write_wakeup
2013-12-06 10:34 ` Huang Shijie
@ 2013-12-06 16:18 ` Peter Hurley
[not found] ` <52A1F8BF.5030204-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org>
0 siblings, 1 reply; 5+ messages in thread
From: Peter Hurley @ 2013-12-06 16:18 UTC (permalink / raw)
To: Huang Shijie; +Cc: gregkh, linux-serial, marcel, linux-bluetooth
On 12/06/2013 05:34 AM, Huang Shijie wrote:
> 于 2013年11月13日 15:30, Huang Shijie 写道:
>> In the uart_handle_cts_change(), uart_write_wakeup() is called after
>> we call @uart_port->ops->start_tx().
>>
>> The Documentation/serial/driver tells us:
>> -----------------------------------------------
>> start_tx(port)
>> Start transmitting characters.
>>
>> Locking: port->lock taken.
>> Interrupts: locally disabled.
>> -----------------------------------------------
>>
>> So when the uart_write_wakeup() is called, the port->lock is taken by
>> the upper. See the following callstack:
>>
>> |_ uart_write_wakeup
>> |_ tty_wakeup
>> |_ ld->ops->write_wakeup
>>
>> With the port->lock held, we call the @write_wakeup. Some implemetation of
>> the @write_wakeup does not notice that the port->lock is held, and it still
>> tries to send data with uart_write() which will try to grab the prot->lock.
>> A dead lock occurs, see the following log caught in the Bluetooth by uart:
>>
>> --------------------------------------------------------------------
>> BUG: spinlock lockup suspected on CPU#0, swapper/0/0
>> lock: 0xdc3f4410, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0
>> CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.10.17-16839-ge4a1bef #1320
>> [<80014cbc>] (unwind_backtrace+0x0/0x138) from [<8001251c>] (show_stack+0x10/0x14)
>> [<8001251c>] (show_stack+0x10/0x14) from [<802816ac>] (do_raw_spin_lock+0x108/0x184)
>> [<802816ac>] (do_raw_spin_lock+0x108/0x184) from [<806a22b0>] (_raw_spin_lock_irqsave+0x54/0x60)
>> [<806a22b0>] (_raw_spin_lock_irqsave+0x54/0x60) from [<802f5754>] (uart_write+0x38/0xe0)
>> [<802f5754>] (uart_write+0x38/0xe0) from [<80455270>] (hci_uart_tx_wakeup+0xa4/0x168)
>> [<80455270>] (hci_uart_tx_wakeup+0xa4/0x168) from [<802dab18>] (tty_wakeup+0x50/0x5c)
>> [<802dab18>] (tty_wakeup+0x50/0x5c) from [<802f81a4>] (imx_rtsint+0x50/0x80)
>> [<802f81a4>] (imx_rtsint+0x50/0x80) from [<802f88f4>] (imx_int+0x158/0x17c)
>> [<802f88f4>] (imx_int+0x158/0x17c) from [<8007abe0>] (handle_irq_event_percpu+0x50/0x194)
>> [<8007abe0>] (handle_irq_event_percpu+0x50/0x194) from [<8007ad60>] (handle_irq_event+0x3c/0x5c)
>> --------------------------------------------------------------------
>>
>> This patch adds more limits to the @write_wakeup, the one who wants to
>> implemet the @write_wakeup should follow the limits which avoid the deadlock.
>>
>> Signed-off-by: Huang Shijie <b32955@freescale.com>
>> ---
>> include/linux/tty_ldisc.h | 5 ++++-
>> 1 files changed, 4 insertions(+), 1 deletions(-)
>>
>> diff --git a/include/linux/tty_ldisc.h b/include/linux/tty_ldisc.h
>> index f15c898..539ccc5 100644
>> --- a/include/linux/tty_ldisc.h
>> +++ b/include/linux/tty_ldisc.h
>> @@ -91,7 +91,10 @@
>> * This function is called by the low-level tty driver to signal
>> * that line discpline should try to send more characters to the
>> * low-level driver for transmission. If the line discpline does
>> - * not have any more data to send, it can just return.
>> + * not have any more data to send, it can just return. If the line
>> + * discipline does have some data to send, please arise a tasklet
>> + * or workqueue to do the real data transfer. Do not send data in
>> + * this hook, it may leads to a deadlock.
>> *
>> * int (*hangup)(struct tty_struct *)
>> *
> just a ping.
>
> In actually, this is a BUG in the tty code or BT code.
hci_uart_tx_wakeup() should perform the actual tx in a work item.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-12-11 11:47 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-11-13 7:30 [PATCH RFC] tty_ldisc: add more limits to the @write_wakeup Huang Shijie
2013-12-06 10:34 ` Huang Shijie
2013-12-06 16:18 ` Peter Hurley
[not found] ` <52A1F8BF.5030204-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org>
2013-12-11 6:44 ` Huang Shijie
2013-12-11 11:47 ` Peter Hurley
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).