Closed zephyrbot closed 8 years ago
by Mariusz Skamra:
by Mariusz Skamra:
by Luiz Augusto von Dentz:
It is deadlocking the RX fiber because there is probably no buffer available to confirm the indication since there is a request pending.
by Mark Linkmeyer:
Luiz Augusto von Dentz , what's the current status on fixing this bug?
by Luiz Augusto von Dentz:
Merged:
commit 6877651a3093fccb55bd7ad3865165e9701fd6f5 Author: Luiz Augusto von Dentz luiz.von.dentz@intel.com Date: Thu Sep 22 18:46:22 2016 +0300
Bluetooth: GATT: Fix locking RX fiber
If an indication is received while there is an outstanding request the
code will attempt to get a buffer from req_pool to confirm which may
block causing the RX fiber to lock and probably crash as the request
won't release the buffer until it gets a response or timeout.
JIRA: GH-2447
Change-Id: I3df30db473a0c6c6c3e63b1d0b410a50bdd3accf
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
by Sharron LIU:
Please reporter verify this.
by Mark Linkmeyer:
Correcting the priority field
Reported by Mariusz Skamra:
In test TC_GAD_CL_BV_02_C PTS sends ATT Indication prior to ATT Find By Type Value Response. Stack handles ATT Indication: [bt] [DBG] bt_recv: (0x20004ee0) buf 0x200016dc len 15 [bt] [DBG] hci_rx_fiber: (0x200066e0) buf 0x200016dc type 3 len 15 [bt] [DBG] hci_acl: (0x200066e0) buf 0x200016dc [bt] [DBG] hci_acl: (0x200066e0) handle 64 len 11 flags 2 [bt] [DBG] bt_conn_ref: (0x200066e0) handle 64 ref 3 [bt] [DBG] bt_conn_recv: (0x200066e0) handle 64 len 11 flags 02 [bt] [DBG] bt_conn_recv: (0x200066e0) First, len 11 final 7 [bt] [DBG] bt_conn_recv: (0x200066e0) rx_len 0 [bt] [DBG] bt_conn_recv: (0x200066e0) Successfully parsed 11 byte L2CAP packet [bt] [DBG] bt_l2cap_recv: (0x200066e0) Packet for CID 4 len 7 [bt] [DBG] l2cap_chan_recv: (0x200066e0) chan 0x200049d8 len 7 [bt] [DBG] bt_att_recv: (0x200066e0) Received ATT code 0x1d len 7 [bt] [DBG] att_indicate: (0x200066e0) handle 0x0012 [bt] [DBG] bt_gatt_notification: (0x200066e0) handle 0x0012 length 4
But ATT Response is not passed to the ATT handler, so that according to the logs it stucks in bt_recv. [bt] [DBG] bt_recv: (0x20004ee0) buf 0x20001744 len 13 [bt] [DBG] bt_recv: (0x20004ee0) buf 0x200014e0 len 7
See btsnoop logs and debug logs attached
v1.5.0-408-ge4b92eb
(Imported from Jira ZEP-940)