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 [off-list ref] 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: <redacted> # 5.18+
Signed-off-by: Your Name <redacted>
Also, this is wrong SOB tag.
Thanks,
--
Masami Hiramatsu (Google) [off-list ref]