arch/risc-v: fix fault handler misattributing kernel faults to user t…#19471
Open
hitHuang wants to merge 1 commit into
Open
arch/risc-v: fix fault handler misattributing kernel faults to user t…#19471hitHuang wants to merge 1 commit into
hitHuang wants to merge 1 commit into
Conversation
…asks riscv_fault_handler() only checked the task type and SYSCALL flag, so a fault taken inside an interrupt handler (running in kernel mode) was blamed on the user task that happened to be interrupted and killed with SIGSEGV, hiding the real kernel bug. Use the STATUS_PPP bit of the trap frame to tell whether the fault originated from user mode: only then is it safe to kill the task. Signed-off-by: liang.huang <liang.huang@houmo.ai>
xiaoxiang781216
approved these changes
Jul 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
If a fault happens inside an interrupt handler,
this_task()returns whatever user task happened to be interrupted, not the code that actually faulted.riscv_fault_handler()didn't distinguish these cases, so it killed that unrelated user task withSIGSEGVinstead of panicking, hiding the real kernel bug.The fix checks the trap frame's previous privilege level (
STATUS_PPP): only a fault that actually came from user mode gets theSIGSEGV-and-kill treatment. Anything trapping from kernel mode (interrupt handlers, syscall bodies, kernel threads) now panics.Impact
Only
CONFIG_BUILD_KERNELis affected. Genuine user-mode faults still get killed withSIGSEGVas before. Faults from kernel-mode code (interrupt handlers, syscall bodies, kernel threads) now panic instead of killing whichever user task happened to be interrupted, so kernel bugs are no longer masked as application bugs.Dependency
Depends on #19468. This fix reads
STATUS_PPPfrom the current trap frame, which is only trustworthy if a nested trap hasn't clobbered it — the exact bug #19468 fixes on qemu-rv.Testing
Config:
CONFIG_BUILD_KERNEL=y.Boards: qemu
rv-virt:knsh(RV32) andrv-virt:knsh64(RV64).For
CONFIG_BUILD_KERNEL, when an interrupt arrives it may interrupt a task running in user mode. If that interrupt handler itself then triggers an unrecoverable exception (e.g. a NULL pointer access causing a crash), the kernel should panic — but the existing implementation only killed the interrupted application instead.To reliably construct a scenario where an interrupt lands exactly while an app is executing in user mode, a modified
helloapp was used:An unrecoverable exception (NULL pointer access) was then deliberately introduced in the tick interrupt handler.
Before fix:
This shows that in this case, only the running application was killed.
After fix:
After the fix, the kernel correctly panics with a full backtrace instead of silently killing
hello.