+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> (cherry picked from commit c05cfbf1)
CRA Git | Maintained and supported by SUSTech CRA and CCSE