tree dd92246bd3c98451daa64576e865fae2ff68d1fc
parent 43c79ba72c07dcc3efd93dc981d646d6e504767f
author Josh DeWitt <josh.dewitt@garmin.com> 1707777717 -0600
committer github-actions[bot] <github-actions[bot]@users.noreply.github.com> 1743208481 +0000

kernel/sched: Re-sort waitq on priority change

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 <josh.dewitt@garmin.com>
(cherry picked from commit c05cfbf15eeb358409eb0bd0b403febd0072f5c9)