Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bluetooth: Host: Fix ATT PDU alloc being non-blocking. #46247

Merged
merged 1 commit into from
Jun 3, 2022

Conversation

hermabe
Copy link
Member

@hermabe hermabe commented Jun 3, 2022

The API is documented as being blocking. Making it non-blocking was an unintentional API change.

Introduced in #44269.

The API is documented as being blocking. Making it nonblocking was an
unintentional API change.

Signed-off-by: Herman Berget <herman.berget@nordicsemi.no>
@@ -542,18 +543,19 @@ struct net_buf *bt_att_chan_create_pdu(struct bt_att_chan *chan, uint8_t op,
case ATT_RESPONSE:
case ATT_CONFIRMATION:
/* Use a timeout only when responding/confirming */
buf = bt_l2cap_create_pdu_timeout(NULL, 0, BT_ATT_TIMEOUT);
timeout = BT_ATT_TIMEOUT;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One issue here is that the timeout is used for both allocations. Potentially, the total timeout is greater than BT_ATT_TIMEOUT.

@carlescufi carlescufi added the bug The issue is a bug, or the PR is fixing a bug label Jun 3, 2022
@carlescufi carlescufi added this to the v3.1.0 milestone Jun 3, 2022
break;
default:
buf = bt_l2cap_create_pdu(NULL, 0);
timeout = K_FOREVER;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a reason to not use BT_ATT_TIMEOUT for all allocations ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ATT timeout is just from a request is sent to the response is received. It is ok to wait before sending a request (and the API is documented as blocking).

@cvinayak
Copy link
Contributor

cvinayak commented Jun 3, 2022

I see this (relates to this #25917):
image

And this (seems new!):
image

But does not cause any faults, the modified central_hr continues normal after the error messages.

@carlescufi carlescufi merged commit ed0dfb9 into zephyrproject-rtos:main Jun 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Bluetooth Host area: Bluetooth bug The issue is a bug, or the PR is fixing a bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants