Skip to content

[Backport v3.7-branch] kernel: Fix priority boost when locking a mutex #87841

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

Merged
merged 1 commit into from
May 31, 2025

Conversation

github-actions[bot]
Copy link

@github-actions github-actions bot commented Mar 29, 2025

Backport c05cfbf from #87235.

Fixes #89331

k_thread_priority_set() on a pended thread wasn't re-inserting into the
waitq, causing the incorrect thread to run based on priority. When using
the scalable waitq config, this can also break assumptions of the tree
and leave the owner of a waitq still being in the waitq tree, cycles in
the tree, or a crash.

Remove and re-add a thread to a waitq to ensure the waitq remains in
order and the tree's assumptions are not violated.

To illustrate the issue, consider 4 threads in decreasing priority
order: A, B, C, and D along with two mutexes, m0 and m1. This is
implemented in the new complex_inversion mutex_api test.
1. D locks m1
2. C locks m0
3. C pends on m1
4. B pends on m1
5. A pends on m0, boosts C's priority, now tree on m1 is not sorted
6. D unlocks m1, left-most thread on tree is B. When removing B from
   tree it cannot be found because it searches to the right of C due to
   C's boosted priority when the node is actually on the left. rb_remove
   silently fails.
7. B unlocks m1, left-most thread on tree is still B and it tries to
   unpend itself, resulting in a NULL pointer dereference on
   B->base.pended_on.

Signed-off-by: Josh DeWitt <[email protected]>
(cherry picked from commit c05cfbf)
@github-actions github-actions bot added the Backport Backport PR and backport failure issues label Mar 29, 2025
@github-project-automation github-project-automation bot moved this to To do in Backports Mar 29, 2025
@dewitt-garmin
Copy link
Contributor

What is the process for getting this approved?

@dewitt-garmin
Copy link
Contributor

Hi,

Is any action required on my part to move this along?

Thanks,
Josh DeWitt

@nashif nashif merged commit f630c6f into v3.7-branch May 31, 2025
33 checks passed
@nashif nashif deleted the backport-87235-to-v3.7-branch branch May 31, 2025 10:38
@github-project-automation github-project-automation bot moved this from Needs more info to Done in Backports May 31, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Kernel Backport Backport PR and backport failure issues
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

6 participants