xiaoxiang781216 commented on PR #19439: URL: https://github.com/apache/nuttx/pull/19439#issuecomment-4987383279
> For a kernel thread, there's no question that dumpstack should return the kernel-mode backtrace. But for a user thread — when it has trapped into the kernel (e.g. blocked inside a syscall) — do we expect dumpstack to return the kernel-stack backtrace, or the user-stack backtrace? > > This PR currently follows the existing design in riscv_backtrace(): regardless of whether the user thread has switched onto a separate kernel stack, up_backtrace() always aims to reconstruct the user-mode call chain — when it has trapped into the kernel stack, it uses xcp.ustkptr (the user-mode SP recorded at the moment of the trap) as an anchor to "bridge" the walk back onto the user stack and continue from there (if I'm understanding this correctly). This fix only corrects implementation-level bugs on top of that existing approach; it doesn't change the direction itself. > > I'm not fully confident that "always walk back to the user stack" is the right/ideal design, and would welcome the community's input either way. walk through both stacks can help the developer identify the problem quickly. If the security is a concern, we can add an option to disable it. > Regardless of which direction is correct, though, it's clear that the current mainline implementation has real bugs — not just on RISC-V, but also in the arm64 implementation for the CONFIG_BUILD_KERNEL case. yes, other arch contains the similar issue need the similar fix too. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
