On 07/04/26 01:23, Aboorva Devarajan wrote:
On Sat, 2026-04-04 at 00:31 +0530, Sourabh Jain wrote:
The kexec sequence invokes enter_vmx_ops() via copy_page() with the MMU
disabled. In this context, code must not rely on normal virtual address
translations or trigger page faults.

With KASAN enabled, functions get instrumented and may access shadow
memory using regular address translation. When executed with the MMU
off, this can lead to page faults (bad_page_fault) from which the
kernel cannot recover in the kexec path, resulting in a hang.

The kexec path sets preempt_count to HARDIRQ_OFFSET before entering
the MMU-off copy sequence.

current_thread_info()->preempt_count = HARDIRQ_OFFSET
   kexec_sequence(..., copy_with_mmu_off = 1)
     -> kexec_copy_flush(image)
          copy_segments()
            -> copy_page(dest, addr)
                 bl enter_vmx_ops()
                    if (in_interrupt())
                      return 0
                 beq .Lnonvmx_copy

Since kexec sets preempt_count to HARDIRQ_OFFSET, in_interrupt()
evaluates to true and enter_vmx_ops() returns early.

As in_interrupt() (and preempt_count()) are always inlined, mark
enter_vmx_ops() with __no_sanitize_address to avoid KASAN
instrumentation and shadow memory access with MMU disabled, helping
kexec boot fine with KASAN enabled.

Cc: Aditya Gupta <[email protected]>
Cc: Daniel Axtens <[email protected]>
Cc: Hari Bathini <[email protected]>
Cc: Madhavan Srinivasan <[email protected]>
Cc: Mahesh Salgaonkar <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Ritesh Harjani (IBM) <[email protected]>
Cc: Shivang Upadhyay <[email protected]>
Cc: Venkat Rao Bagalkote <[email protected]>
Reported-by: Aboorva Devarajan <[email protected]>
Signed-off-by: Sourabh Jain <[email protected]>
---
Changelog:

v2:
- Remove __no_sanitize_address from exit_vmx_ops
- Add a comment explaining that marking only enter_vmx_ops
   with __no_sanitize_address is sufficient for kexec to
   function properly with KASAN enabled

v1:
https://lore.kernel.org/all/[email protected]/
---
  arch/powerpc/lib/vmx-helper.c | 9 ++++++++-
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/lib/vmx-helper.c b/arch/powerpc/lib/vmx-helper.c
index 554b248002b4..57e897b60db8 100644
--- a/arch/powerpc/lib/vmx-helper.c
+++ b/arch/powerpc/lib/vmx-helper.c
@@ -52,7 +52,14 @@ int exit_vmx_usercopy(void)
  }
  EXPORT_SYMBOL(exit_vmx_usercopy);
-int enter_vmx_ops(void)
+/*
+ * Can be called from kexec copy_page() path with MMU off. The kexec
+ * code sets preempt_count to HARDIRQ_OFFSET so we return early here.
+ * Since in_interrupt() is always inline, __no_sanitize_address on this
+ * function is sufficient to avoid KASAN shadow memory accesses in real
+ * mode.
+ */
+int __no_sanitize_address enter_vmx_ops(void)
  {
        if (in_interrupt())
                return 0;

Without these patches, when KASAN is enabled, I observe a hang during kexec 
boot on
pseries (PowerVM):

[ 3459.012617][ T4209] kexec_core: Starting new kernel
[ 3459.012814][ T4209] kexec: waiting for cpu 1 (physical 1) to enter 2 state
[ 3459.016236][ T4209] kexec: waiting for cpu 11 (physical 11) to enter 2 state
[ 3459.016287][ T4209] kexec: waiting for cpu 12 (physical 12) to enter 2 state
[ 3459.016380][ T4209] kexec: waiting for cpu 13 (physical 13) to enter 2 state
[ 3459.016418][ T4209] kexec: waiting for cpu 14 (physical 14) to enter 2 state
[ 3459.016444][ T4209] kexec: waiting for cpu 15 (physical 15) to enter 2 state
[ 3459.016462][ T4209] kexec: waiting for cpu 18 (physical 18) to enter 2 state
[ 3459.271929][ T4209] kexec: Starting switchover sequence.
[system hangs here and no further progress]

==============

With both the patches applied, kexec completes successfully with KASAN enabled.

Reviewed-by: Aboorva Devarajan <[email protected]>
Tested-by: Aboorva Devarajan <[email protected]>

Thanks for testing and the review.

- Sourabh Jain

Reply via email to