Bluetooth: L2CAP: Deadlock when there are no free buffers while transmitting on multiple channels #34600
Description
Describe the bug
Transmitting many large SDUs as quickly as possible on multiple L2CAP channels quickly fills a lot of buffers. When no more segments can be queued to be transmitted because there are no more free buffers, or there are no more credits for the channel, queuing of segments is stopped. Whenever a previously queued segment has been transmitted, or more credits are received, segments are again being queued for transmission. If there are still no free buffers, queuing of segments is stopped again right away. If this happens when all segments that have previously been queued on the channel have already been transmitted, and there are no more credits to receive, queuing of segments is stopped indefinitely.
Expected behavior
Queuing of segments continues when there are free buffers available.
Impact
Annoyance.
Environment (please complete the following information):
- OS: Linux
- Toolchain (e.g Zephyr SDK, ...)
- nrfconnect/sdk-zephyr@6a1d340
Additional context
It is possible to work around this by having a high enough number of buffers (CONFIG_BT_L2CAP_TX_BUF_COUNT or CONFIG_BT_CONN_TX_MAX) that there are always buffers available when queuing of segments is restarted.