[nrf noup] bluetooth: att: Fix CONFIG_BT_ATT_SENT_CB_AFTER_TX
#3323
+26
−10
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
alwa-nordic
requested changes
Sep 30, 2025
There was a problem hiding this comment.
Let's revert the old no-up that's broken and reapply the whole fixed feature as one commit. This will help us keep no-ups manageable and help us verify the fix.
The fix seems dubious. We need to clarify some things. Why is there a && (buf->ref == 1)? And why does the comment say "might"?
The comment should also be rephrased to more clearly state where the reference was taken, and ideally what the reference is currently "attached to" in a way that makes it easy to show that getting rid of it here is correct.
MarekPieta
force-pushed
the
fix_att_sent_cb_after_tx
branch
2 times, most recently
from
7bea193 to
6791da9
Compare
MarekPieta
force-pushed
the
fix_att_sent_cb_after_tx
branch
from
6791da9 to
5d62bf5
Compare
|
Pure rebase |
kapi-no
approved these changes
Oct 3, 2025
alwa-nordic
requested changes
Oct 6, 2025
MarekPieta
force-pushed
the
fix_att_sent_cb_after_tx
branch
from
5d62bf5 to
a15f0aa
Compare
|
Cherry-picked the zephyrproject-rtos/zephyr#97056 to trigger NCS CI tests |
alwa-nordic
approved these changes
Oct 8, 2025
MarekPieta
force-pushed
the
fix_att_sent_cb_after_tx
branch
from
a15f0aa to
940c8ae
Compare
|
Pure rebase |
kapi-no
approved these changes
Oct 8, 2025
MarekPieta
force-pushed
the
fix_att_sent_cb_after_tx
branch
from
940c8ae to
eacf227
Compare
…nd_buf" This reverts commit adb8f4e. Signed-off-by: Marek Pieta <Marek.Pieta@nordicsemi.no>
…p_send_pdu" This reverts commit 510e36c. Signed-off-by: Marek Pieta <Marek.Pieta@nordicsemi.no>
… TX is done" This reverts commit d1d9b2d. Signed-off-by: Marek Pieta <Marek.Pieta@nordicsemi.no>
By default, the BLE stack calls sent callback for ATT data when the data is passed to BLE controller for transmission. Enabling this Kconfig option delays calling the sent callback until data transmission is finished by BLE controller (the callback is delayed until receiving the Number of Completed Packets HCI Event). If the ATT sent callback is delayed until data transmission is done by BLE controller, the transmitted buffer may have an additional reference. The reference is used to extend lifetime of the net buffer until the data transmission is confirmed by ACK of the remote. Jira: NCSDK-27422 Jira: NCSDK-28624 Jira: NCSDK-35650 Signed-off-by: Marek Pieta <Marek.Pieta@nordicsemi.no>
…eleted When bt_l2cap_send_pdu() succeeds, it transfers buffer ownership to the stack, which must eventually invoke the provided callback. This contract is honored in all paths where transmission becomes impossible: - Normal transmission: callback invoked with err=0 after HCI Number of Completed Packets event (tx_notify_process) - Send errors (after tx allocated): callback invoked with err=-ESHUTDOWN via conn_tx_destroy - Send errors (before tx allocated): callback invoked with the specific error code in send_buf error_return path - Connection disconnect: callbacks invoked with err=-ESHUTDOWN via process_unack_tx -> conn_tx_destroy for all PDUs in tx_pending However, when a channel is deleted (l2cap_chan_del), PDUs remaining in the tx_queue are dropped without invoking their callbacks, violating the ownership contract. Fix this by extracting and invoking any non-NULL callbacks from the closure stored in buf->user_data before releasing the buffers. The callback is invoked with err=-ESHUTDOWN, making this path analogous to process_unack_tx: both drain queues of unsent PDUs when transmission becomes impossible due to external events (channel deletion vs connection disconnect). The only difference is the buffer lifecycle stage - in l2cap_chan_del, PDUs are still in tx_queue (closure in buf->user_data), while in process_unack_tx, they've progressed to tx_pending (callback in bt_conn_tx struct). Note: conn_tx_destroy() cannot be used here because no bt_conn_tx struct has been allocated yet - the closure is still in buf->user_data. Upstream PR #: 97056 Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
MarekPieta
force-pushed
the
fix_att_sent_cb_after_tx
branch
from
eacf227 to
f162b80
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
delay ATT sent callback until data transmission is done by controllerfeature introduces an extranet_bufreference which is removed on sent callback. Make sure to remove the reference on BLE disconnection to free the buffer as the registered sent callback will not be called.Jira: NCSDK-35650