Repository navigation
Support TX_ENABLE_STACK_CHECKING for module threads - #820
Tisya-Gupta wants to merge 1 commit into
Conversation
|
Hey @Tisya-Gupta, I reviewed and noticed a few quick things that need fixing. Mainly, checking stack_start == kernel_stack_start in the macro breaks when TXM_MODULE_KERNEL_STACK_MAINTENANCE_DISABLE is defined, which causes false stack overflow errors. There's also a boundary issue where reading before stack_start happens when the stack is full, and the kernel guard word placement doesn't match the user stack convention. Also, per #702, we really need this tested on actual Cortex-M/A hardware rather than just the host mock test. Lastly, please update the commit title to past tense (Added support...), use the Cause:, Fix:, Test result: format in the commit body, and drop the 2024 Microsoft copyright from the new test file. Could you please push these updates? Thanks! |
|
Hi @Tisya-Gupta. Thank you for this contribution. @Dev10-sys's comments look accurate to me, but I will provide a comprehensive review next week. |
|
Thank you @fdesbiens and @Dev10-sys for the reviews. I will work on the requested changes.... |
Fixes eclipse-threadx#702 Cause: User-mode module threads operate with two separate stacks: an unprivileged user stack and a privileged kernel stack allocated by the module manager. When a module thread enters the kernel, the scheduler swaps execution over to the kernel stack. Previously, TX_ENABLE_STACK_CHECKING only tracked tx_thread_stack_highest_ptr against the active stack without distinguishing between user and kernel mode. This caused cross-stack pointer corruption, false positive stack overflow detections upon returning to user mode, and potential out-of-bounds reads when highest_ptr equaled stack_start. Additionally, kernel stack creation did not reserve a guard word at the end outside the usable stack boundary, and MISRA-C mode stack check wrappers bypassed kernel stack verification entirely. Fix: - Added tx_thread_module_kernel_stack_highest_ptr alias mapping to tx_thread_module_reserved to track kernel stack usage independently without increasing control block size. - Reserved an aligned guard word at tx_thread_module_kernel_stack_end outside usable stack space in txm_module_manager_thread_create. - Updated TX_THREAD_STACK_CHECK (both standard and MISRA-C implementations) to select between kernel and user stacks based on current execution mode, supporting targets with TXM_MODULE_KERNEL_STACK_MAINTENANCE_DISABLE, and guarded against buffer under-reads when highest_ptr equals stack_start. - Updated _tx_thread_stack_analyze to track execution stack state across interrupt restores and prevent cross-stack address comparisons during binary search. - Added host unit test suite covering user mode, kernel mode, stack switching, guard corruption detection, overflow detection, maintenance-disabled mode, and boundary conditions. Test result: Module manager test suite passed all 10 unit tests (including 18 assertions in threadx_module_manager_thread_stack_checking_test) cleanly with zero errors and zero warnings. Signed-off-by: Tisya-Gupta <tisyagupta793@gmail.com>
b9d81c4 to
ea37813
Compare
Fixes #702
In this PR, I added stack checking support for module threads when TX_ENABLE_STACK_CHECKING is turned on. Module threads switch between a user stack and a kernel stack, but previously there was no separate pointer tracking the kernel stack and no guard word reserved at the end of the kernel stack buffer, which caused false stack overflow errors when switching between modes.
To solve this, I reserved space for the guard pattern at the end of the kernel stack buffer during thread creation and initialized its highest usage pointer. I used the existing tx_thread_module_reserved field in the thread control block to track the kernel stack usage, avoiding any need to touch assembly code. I also updated TX_THREAD_STACK_CHECK and _tx_thread_stack_analyze to check the right stack depending on whether the thread is currently running in kernel mode or user mode, and added unit tests to verify both user and kernel stack checks.