+10
−0
+290
−0
Loading
Gitlab 现已全面支持 git over ssh 与 git over https。通过 HTTPS 访问请配置带有 read_repository / write_repository 权限的 Personal access token。通过 SSH 端口访问请使用 22 端口或 13389 端口。如果使用CAS注册了账户但不知道密码,可以自行至设置中更改;如有其他问题,请发邮件至 service@cra.moe 寻求协助。
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>
CRA Git | Maintained and supported by SUSTech CRA and CCSE