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

[backport v2.7-branch] Bluetooth: Controller: Control procedure error code and compiler re-ordering fixes #74140

Conversation

cvinayak
Copy link
Contributor

@cvinayak cvinayak commented Jun 12, 2024

A Host shall consider any error code that it does not
explicitly understand equivalent to the error code
Unspecified Error (0x1F).

Refactor reused function in BT_CTLR_LE_ENC feature.|

In ull_disable, it is imperative that the callback is set up before a
second reference counter check, otherwise it may happen that an LLL done
event has already passed when the disable callback and semaphore is
assigned.

This causes the HCI thread to wait until timeout and assert after
ull_ticker_stop_with_mark.

For certain compilers, due to compiler optimizations, it can be seen
from the assembler code that the callback is assigned after the second
reference counter check.

By adding memory barriers, the code correctly reorders code to the
expected sequence.

Fixes #75981.

mtpr-ot and others added 3 commits June 12, 2024 10:55
In ull_disable, it is imperative that the callback is set up before a
second reference counter check, otherwise it may happen that an LLL done
event has already passed when the disable callback and semaphore is
assigned.

This causes the HCI thread to wait until timeout and assert after
ull_ticker_stop_with_mark.

For certain compilers, due to compiler optimizations, it can be seen
from the assembler code that the callback is assigned after the second
reference counter check.

By adding memory barriers, the code correctly reorders code to the
expected sequence.

Signed-off-by: Morten Priess <[email protected]>
Refactor reused function in BT_CTLR_LE_ENC feature.

Signed-off-by: Vinayak Kariappa Chettimada <[email protected]>
A Host shall consider any error code that it does not
explicitly understand equivalent to the error code
Unspecified Error (0x1F).

Signed-off-by: Vinayak Kariappa Chettimada <[email protected]>
@cfriedt
Copy link
Member

cfriedt commented Jul 23, 2024

Just a note that native_posix builds are causing v2.7-branch build failures. I'll take a look at it in a bit, but I would say it's relatively low priority, and not blocking anything.

Also, I am currently unable to merge in v2.7-branch (?)

@cvinayak
Copy link
Contributor Author

What to do with this PR? do I need to rebase and get approvals again?

@cfriedt
Copy link
Member

cfriedt commented Sep 14, 2024

@cvinayak - I couldn't find an issues manually running the CI testplan.

I'll close and reopen this PR to retrigger, and you will have my approval already.

@cfriedt cfriedt closed this Sep 14, 2024
@cfriedt cfriedt reopened this Sep 14, 2024
@cfriedt
Copy link
Member

cfriedt commented Sep 14, 2024

@stephanosio, @nashif - any idea about this one? The job output looks as though we aren't getting the requested runner.

Requested labels: zephyr-runner-linux-x64-4xlarge
Job defined at: zephyrproject-rtos/zephyr/.github/workflows/clang.yaml@refs/heads/v2.7-branch
Waiting for a runner to pick up this job...

Copy link

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants