Skip to content

Conversation

@KyraLengfeld
Copy link
Contributor

Cherry picks the four commits from zephyrproject-rtos/zephyr#97913 to run tx_processor on its own thread.

alwa-nordic and others added 4 commits December 4, 2025 15:24
ATT is invoking user callbacks in its net_buf destroy function. It is
common practice that these callbacks can block on bt_hci_cmd_alloc().
This is a deadlock when the net_buf_unref() happens inside the HCI
driver, invoked from tx_processor.

Blocking callbacks like this appear in our own samples. See further down
about how this problem was detected.

tx_processor not protect against blocking callbacks so it is de-facto
forbidden. The Host should not equip net_bufs with dangerous destroy
callbacks.

This commit makes ATT defer its net_buf destruction and user callback
invocation to the system workqueue, so that net_buf_unref is safe to
call from non-blocking threads. In the case of the deadlock, the
net_buf_unref() was below the tx_processor in the call stack, which (at
the time of this commit) is on the system work queue, so defering it to
the system work queue is preserving the existing behavior.

Future improvement may be to allow the user to provide their own
workqueue for ATT callbacks.

This deadlock was detected because the following test was failing while
moving tx_processor to the bt_taskq:

    tests/bsim/bluetooth/ll/throughput/tests_scripts/gatt_write.sh

The above test has an ATT callback `write_cmd_cb` invokes
`bt_conn_le_param_update` can block waiting for `tx_processor`.

The reason it was not failing while tx_processor was on the system work
queue is that the GATT API has a special non-blocking behavior when
called from the system work queue.

Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
(cherry picked from commit 6889042)
Signed-off-by: Kyra Lengfeld <kyra.lengfeld@nordicsemi.no>
…al_identity

Reduce BT_MAX_CONN from 62 to 61 to make it build on integration
platform qemu_cortex_m3/ti_lm3s6965 when we add bt_taskq in subsequent
commit.

The number 62 seems arbitrary here, so reducing it by one should not
have any practical impact.

Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
(cherry picked from commit 0ee5d70)
Signed-off-by: Kyra Lengfeld <kyra.lengfeld@nordicsemi.no>
When thread that TX processor is used to send commands and data to
Controller is also used for sync commands sending and command buffer
allocation, a deadlock happens.

This thread is used to avoid such deadlocks by moving TX processor to
its own dedicated thread exclusively used by tx processor only.

Co-authored-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
(cherry picked from commit f101976)
Signed-off-by: Kyra Lengfeld <kyra.lengfeld@nordicsemi.no>
The workaround in bt_cmd_send_sync should no longer by needed when
tx_processor is not on the system work queue.

Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
(cherry picked from commit 04b8dba)
Signed-off-by: Kyra Lengfeld <kyra.lengfeld@nordicsemi.no>
NordicBuilder added a commit to NordicBuilder/sdk-nrf that referenced this pull request Dec 4, 2025
Automatically created by action-manifest-pr GH action from PR:
nrfconnect/sdk-zephyr#3606

Signed-off-by: Nordic Builder <pylon@nordicsemi.no>
KyraLengfeld pushed a commit to NordicBuilder/sdk-nrf that referenced this pull request Dec 5, 2025
Automatically created by action-manifest-pr GH action from PR:
nrfconnect/sdk-zephyr#3606

Signed-off-by: Nordic Builder <pylon@nordicsemi.no>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants