[PATCH v2 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o

[PATCH v2 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o

[Sourabh Jain]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 2220 bytes --]

KASAN instrumentation is intended to be disabled for the kexec core
code, but the existing Makefile entry misses the object suffix. As a
result, the flag is not applied correctly to core_$(BITS).o.

So when KASAN is enabled, kexec_copy_flush and copy_segments in
kexec/core_64.c are instrumented, which can result in accesses to
shadow memory via normal address translation paths. Since these run
with the MMU disabled, such accesses may trigger page faults
(bad_page_fault) that cannot be handled in the kdump path, ultimately
causing a hang and preventing the kdump kernel from booting. The same
is true for kexec as well, since the same functions are used there.

Update the entry to include the “.o” suffix so that KASAN
instrumentation is properly disabled for this object file.

Fixes: 2ab2d5794f14 ("powerpc/kasan: Disable address sanitization in kexec paths")
Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Closes: https://lore.kernel.org/all/1dee8891-8bcc-46b4-93f3-fc3a774abd5b@linux.ibm.com/
Cc: Aboorva Devarajan <aboorvad@linux.ibm.com>
Cc: Aditya Gupta <adityag@linux.ibm.com>
Cc: Daniel Axtens <dja@axtens.net>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Acked-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
---
Changelog:

v2:
- Add Reviewed-by, Acked-by and Tested-by tags
- No functional changes
 
 v1:
 https://lore.kernel.org/all/20260321053121.614022-1-sourabhjain@linux.ibm.com/
---
 arch/powerpc/kexec/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kexec/Makefile b/arch/powerpc/kexec/Makefile
index 470eb0453e17..ec7a0eed75dc 100644
--- a/arch/powerpc/kexec/Makefile
+++ b/arch/powerpc/kexec/Makefile
@@ -16,4 +16,4 @@ GCOV_PROFILE_core_$(BITS).o := n
 KCOV_INSTRUMENT_core_$(BITS).o := n
 UBSAN_SANITIZE_core_$(BITS).o := n
 KASAN_SANITIZE_core.o := n
-KASAN_SANITIZE_core_$(BITS) := n
+KASAN_SANITIZE_core_$(BITS).o := n
-- 
2.52.0

[PATCH v2 2/2] powerpc/vmx: avoid KASAN instrumentation in enter_vmx_ops() for kexec

[Sourabh Jain]

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 <adityag@linux.ibm.com>
Cc: Daniel Axtens <dja@axtens.net>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
Cc: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Reported-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
---
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/20260321053121.614022-1-sourabhjain@linux.ibm.com/
---
 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;
-- 
2.52.0

Re: [PATCH v2 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o

[Ritesh Harjani]

Sourabh Jain <sourabhjain@linux.ibm.com> writes:

> KASAN instrumentation is intended to be disabled for the kexec core
> code, but the existing Makefile entry misses the object suffix. As a
> result, the flag is not applied correctly to core_$(BITS).o.
>
> So when KASAN is enabled, kexec_copy_flush and copy_segments in
> kexec/core_64.c are instrumented, which can result in accesses to
> shadow memory via normal address translation paths. Since these run
> with the MMU disabled, such accesses may trigger page faults
> (bad_page_fault) that cannot be handled in the kdump path, ultimately
> causing a hang and preventing the kdump kernel from booting. The same
> is true for kexec as well, since the same functions are used there.
>
> Update the entry to include the “.o” suffix so that KASAN
> instrumentation is properly disabled for this object file.
>
> Fixes: 2ab2d5794f14 ("powerpc/kasan: Disable address sanitization in kexec paths")
> Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
> Closes: https://lore.kernel.org/all/1dee8891-8bcc-46b4-93f3-fc3a774abd5b@linux.ibm.com/
> Cc: Aboorva Devarajan <aboorvad@linux.ibm.com>
> Cc: Aditya Gupta <adityag@linux.ibm.com>
> Cc: Daniel Axtens <dja@axtens.net>
> Cc: Hari Bathini <hbathini@linux.ibm.com>
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Shivang Upadhyay <shivangu@linux.ibm.com>

I guess you missed adding:
Cc: stable@vger.kernel.org

> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
> Acked-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> ---
> Changelog:
>
> v2:
> - Add Reviewed-by, Acked-by and Tested-by tags
> - No functional changes
>  
>  v1:
>  https://lore.kernel.org/all/20260321053121.614022-1-sourabhjain@linux.ibm.com/
> ---
>  arch/powerpc/kexec/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kexec/Makefile b/arch/powerpc/kexec/Makefile
> index 470eb0453e17..ec7a0eed75dc 100644
> --- a/arch/powerpc/kexec/Makefile
> +++ b/arch/powerpc/kexec/Makefile
> @@ -16,4 +16,4 @@ GCOV_PROFILE_core_$(BITS).o := n
>  KCOV_INSTRUMENT_core_$(BITS).o := n
>  UBSAN_SANITIZE_core_$(BITS).o := n
>  KASAN_SANITIZE_core.o := n
> -KASAN_SANITIZE_core_$(BITS) := n
> +KASAN_SANITIZE_core_$(BITS).o := n
> -- 
> 2.52.0

Re: [PATCH v2 2/2] powerpc/vmx: avoid KASAN instrumentation in enter_vmx_ops() for kexec

[Ritesh Harjani]

Sourabh Jain <sourabhjain@linux.ibm.com> writes:

> 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.
>

Nice! LGTM. Please feel free to add:
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>

> Cc: Aditya Gupta <adityag@linux.ibm.com>
> Cc: Daniel Axtens <dja@axtens.net>
> Cc: Hari Bathini <hbathini@linux.ibm.com>
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
> Cc: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
> Reported-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> ---
> 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/20260321053121.614022-1-sourabhjain@linux.ibm.com/
> ---
>  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;
> -- 
> 2.52.0

Re: [PATCH v2 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o

[Sourabh Jain]

On 04/04/26 06:27, Ritesh Harjani (IBM) wrote:
> Sourabh Jain <sourabhjain@linux.ibm.com> writes:
>
>> KASAN instrumentation is intended to be disabled for the kexec core
>> code, but the existing Makefile entry misses the object suffix. As a
>> result, the flag is not applied correctly to core_$(BITS).o.
>>
>> So when KASAN is enabled, kexec_copy_flush and copy_segments in
>> kexec/core_64.c are instrumented, which can result in accesses to
>> shadow memory via normal address translation paths. Since these run
>> with the MMU disabled, such accesses may trigger page faults
>> (bad_page_fault) that cannot be handled in the kdump path, ultimately
>> causing a hang and preventing the kdump kernel from booting. The same
>> is true for kexec as well, since the same functions are used there.
>>
>> Update the entry to include the “.o” suffix so that KASAN
>> instrumentation is properly disabled for this object file.
>>
>> Fixes: 2ab2d5794f14 ("powerpc/kasan: Disable address sanitization in kexec paths")
>> Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
>> Closes: https://lore.kernel.org/all/1dee8891-8bcc-46b4-93f3-fc3a774abd5b@linux.ibm.com/
>> Cc: Aboorva Devarajan <aboorvad@linux.ibm.com>
>> Cc: Aditya Gupta <adityag@linux.ibm.com>
>> Cc: Daniel Axtens <dja@axtens.net>
>> Cc: Hari Bathini <hbathini@linux.ibm.com>
>> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>> Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
> I guess you missed adding:
> Cc: stable@vger.kernel.org

You’re right, I missed it.
I’ll include it in the next revision.

Thanks,
Sourabh Jain

Re: [PATCH v2 2/2] powerpc/vmx: avoid KASAN instrumentation in enter_vmx_ops() for kexec

[Sourabh Jain]

On 04/04/26 06:31, Ritesh Harjani (IBM) wrote:
> Sourabh Jain <sourabhjain@linux.ibm.com> writes:
>
>> 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.
>>
> Nice! LGTM. Please feel free to add:
> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>

Thanks, Ritesh!

Will add your Reviewed-by tag in the next version.

- Sourabh Jain

Re: [PATCH v2 2/2] powerpc/vmx: avoid KASAN instrumentation in enter_vmx_ops() for kexec

[Aboorva Devarajan]

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 <adityag@linux.ibm.com>
> Cc: Daniel Axtens <dja@axtens.net>
> Cc: Hari Bathini <hbathini@linux.ibm.com>
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
> Cc: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
> Reported-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> ---
> 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/20260321053121.614022-1-sourabhjain@linux.ibm.com/
> ---
>  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 <aboorvad@linux.ibm.com>
Tested-by: Aboorva Devarajan <aboorvad@linux.ibm.com>

Thanks,
Aboorva

Re: [PATCH v2 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o

[Aboorva Devarajan]

On Sat, 2026-04-04 at 00:31 +0530, Sourabh Jain wrote:
> KASAN instrumentation is intended to be disabled for the kexec core
> code, but the existing Makefile entry misses the object suffix. As a
> result, the flag is not applied correctly to core_$(BITS).o.
> 
> So when KASAN is enabled, kexec_copy_flush and copy_segments in
> kexec/core_64.c are instrumented, which can result in accesses to
> shadow memory via normal address translation paths. Since these run
> with the MMU disabled, such accesses may trigger page faults
> (bad_page_fault) that cannot be handled in the kdump path, ultimately
> causing a hang and preventing the kdump kernel from booting. The same
> is true for kexec as well, since the same functions are used there.
> 
> Update the entry to include the “.o” suffix so that KASAN
> instrumentation is properly disabled for this object file.
> 
> Fixes: 2ab2d5794f14 ("powerpc/kasan: Disable address sanitization in
> kexec paths")
> Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
> Closes:
> https://lore.kernel.org/all/1dee8891-8bcc-46b4-93f3-fc3a774abd5b@linux.ibm.com/
> Cc: Aboorva Devarajan <aboorvad@linux.ibm.com>
> Cc: Aditya Gupta <adityag@linux.ibm.com>
> Cc: Daniel Axtens <dja@axtens.net>
> Cc: Hari Bathini <hbathini@linux.ibm.com>
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
> Acked-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> ---
> Changelog:
> 
> v2:
> - Add Reviewed-by, Acked-by and Tested-by tags
> - No functional changes
>  
>  v1:
>  
> https://lore.kernel.org/all/20260321053121.614022-1-sourabhjain@linux.
> ibm.com/
> ---
>  arch/powerpc/kexec/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/kexec/Makefile
> b/arch/powerpc/kexec/Makefile
> index 470eb0453e17..ec7a0eed75dc 100644
> --- a/arch/powerpc/kexec/Makefile
> +++ b/arch/powerpc/kexec/Makefile
> @@ -16,4 +16,4 @@ GCOV_PROFILE_core_$(BITS).o := n
>  KCOV_INSTRUMENT_core_$(BITS).o := n
>  UBSAN_SANITIZE_core_$(BITS).o := n
>  KASAN_SANITIZE_core.o := n
> -KASAN_SANITIZE_core_$(BITS) := n
> +KASAN_SANITIZE_core_$(BITS).o := n


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

Reviewed-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Tested-by: Aboorva Devarajan <aboorvad@linux.ibm.com>

Thanks,
Aboorva

Re: [PATCH v2 2/2] powerpc/vmx: avoid KASAN instrumentation in enter_vmx_ops() for kexec

[Sourabh Jain]

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 <adityag@linux.ibm.com>
>> Cc: Daniel Axtens <dja@axtens.net>
>> Cc: Hari Bathini <hbathini@linux.ibm.com>
>> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
>> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>> Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
>> Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
>> Cc: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
>> Reported-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
>> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
>> ---
>> 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/20260321053121.614022-1-sourabhjain@linux.ibm.com/
>> ---
>>   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 <aboorvad@linux.ibm.com>
> Tested-by: Aboorva Devarajan <aboorvad@linux.ibm.com>

Thanks for testing and the review.

- Sourabh Jain