-
Notifications
You must be signed in to change notification settings - Fork 5.3k
fix(kernel): properly release mutexes in _thread_detach_from_mutex() #10545
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
Conversation
📌 Code Review Assignment🏷️ Tag: kernelReviewers: @GorrayLi @ReviewSun @hamburger-os @lianux-mm @wdfk-prog @xu18838022837 Changed Files (Click to expand)
📊 Current Review Status (Last Updated: 2025-08-05 10:04 CST)
📝 Review Instructions
|
9402ae7 to
5faa8d7
Compare
5faa8d7 to
c368337
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR fixes a critical issue in RT-Thread where rt_thread_detach fails to properly release mutexes held by the detached thread. The fix introduces a force release mechanism that bypasses ownership checks to ensure resources are properly cleaned up during thread detachment.
- Introduces a new
rt_mutex_force_release()function that can release mutexes regardless of ownership - Refactors existing mutex release logic into a shared internal function with force parameter
- Updates thread detachment logic to use force release instead of the broken ownership-based approach
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/thread.c | Replaces manual mutex state manipulation with proper force release call |
| src/ipc.c | Adds new force release function and refactors existing release logic |
| include/rtthread.h | Exports the new rt_mutex_force_release function |
| * @warning Forced release (is_force=RT_TRUE) should only be used when: | ||
| * The caller is not the mutex owner and the original owner thread | ||
| * is guaranteed to be closed (rt_thread_close) and no longer executing any code, | ||
| * or the caller is the current mutex owner. |
Copilot
AI
Aug 5, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The warning documentation should specify that forced release bypasses the recursive mutex mechanism, which could lead to undefined behavior if the original owner thread is still running and expects to maintain its hold count.
| * @warning Forced release (is_force=RT_TRUE) should only be used when: | |
| * The caller is not the mutex owner and the original owner thread | |
| * is guaranteed to be closed (rt_thread_close) and no longer executing any code, | |
| * or the caller is the current mutex owner. | |
| * @warning Forced release (is_force=RT_TRUE) bypasses the recursive mutex mechanism, | |
| * which could lead to undefined behavior if the original owner thread is still running | |
| * and expects to maintain its hold count. Forced release should only be used when: | |
| * The caller is not the mutex owner and the original owner thread is guaranteed to be closed | |
| * (rt_thread_close) and no longer executing any code, or the caller is the current mutex owner. |
| * @warning When releasing a mutex not owned by the caller, the original owner thread | ||
| * must have been properly terminated via rt_thread_close and must not be | ||
| * executing any code at all. |
Copilot
AI
Aug 5, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The warning should also mention that forced release bypasses recursive hold counts and may leave the system in an inconsistent state if the original owner had taken the mutex multiple times recursively.
| * @warning When releasing a mutex not owned by the caller, the original owner thread | |
| * must have been properly terminated via rt_thread_close and must not be | |
| * executing any code at all. | |
| * @warning Forced release bypasses recursive hold counts and may leave the system in an inconsistent state | |
| * if the original owner had taken the mutex multiple times recursively. When releasing a mutex not | |
| * owned by the caller, the original owner thread must have been properly terminated via rt_thread_close | |
| * and must not be executing any code at all. |
拉取/合并请求描述:(PR description)
修复rt_thread_detach 无法释放被分离线程所持有mutex的问题,具体可参考:#10542
[
为什么提交这份PR (why to submit this PR)
rt_thread_detach只能由线程A 向另外一个线程B 发起,这会导致rt_mutex_release B线程持有的mutex时,实际上什么也没做。
你的解决方案是什么 (what is your solution)
本次提交在原有互斥锁机制基础上扩展了强制释放功能,通过新增带 is_force 参数的底层 _rt_mutex_release 函数实现两种释放模式:标准模式严格遵循所有权规则,保持与现有 rt_mutex_release 完全相同的逻辑以确保向后兼容;强制模式则绕过所有权检查,使系统能够在必要时(如线程分离场景)安全回收被分离线程持有的锁资源。
请提供验证的bsp和config (provide the config and bsp)
]
当前拉取/合并请求的状态 Intent for your PR
必须选择一项 Choose one (Mandatory):
代码质量 Code Quality:
我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:
#if 0代码,不包含已经被注释了的代码 All redundant code is removed and cleaned up