Hi 3791971891, At least, you must use your real name for sending a patch. Please read Documentation/process/submitting-patches.rst.
On Thu, 22 Oct 2026 16:20:44 +0800, 3791971891 <[email protected]> wrote: > The current rethook trampoline implementation across LoongArch, ARM64 and > RISC-V > manually saves and restores architecture-specific percpu base registers (r21 > on > LoongArch, x18 on ARM64, tp on RISC-V) around the call to > rethook_trampoline_handler(). What kernel version are you working on? At least arch/arm64/kernel/rethook_trampoline.S does not exist. > This pattern is fundamentally unsafe. rethook_trampoline_handler() runs in a > preemptible context where CPU migration is allowed. If a task migrates from > CPU0 > to CPU1 during handler execution, the kernel context switch and exception > return > logic will have already updated the percpu base register to point to the new > CPU's > per-cpu data area. Restoring the stale value saved on the old CPU leaves the > register pointing to the wrong per-cpu region, triggering: > 1. Remote CPU runqueue/RCU state corruption > 2. "Scheduling while atomic" warnings > 3. Unrecoverable RCU stalls and hard CPU lockups > 4. Silent per-cpu counter/lock data corruption Your email client replaces ASCII whitespace with UTF-8. Please do not do that. > > > The percpu base register is exclusively managed by kernel exception > entry/exit and > context switch paths. It must never be manually saved and restored by > instrumented > trampoline code — the kernel guarantees the correct value is present on return > from any C function call across preemption events. > > > This patch removes the dangerous and unnecessary save/restore instructions for > percpu base registers in all three architecture rethook trampoline > implementations, > eliminating the cross-CPU migration race entirely. > > > Fixes: 90a279c6c83a ("rethook: Add core infrastructure for return hook") > Cc: <[email protected]> # 5.18+ > Signed-off-by: Your Name <[email protected]> Also, this is wrong SOB tag. Thanks, -- Masami Hiramatsu (Google) <[email protected]>
