* [PATCH v2 2/2] powerpc/vmx: avoid KASAN instrumentation in enter_vmx_ops() for kexec
2026-04-03 19:01 [PATCH v2 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o Sourabh Jain
@ 2026-04-03 19:01 ` Sourabh Jain
2026-04-04 1:01 ` Ritesh Harjani
2026-04-06 19:53 ` Aboorva Devarajan
2026-04-04 0:57 ` [PATCH v2 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o Ritesh Harjani
2026-04-06 19:55 ` Aboorva Devarajan
2 siblings, 2 replies; 9+ messages in thread
From: Sourabh Jain @ 2026-04-03 19:01 UTC (permalink / raw)
To: linuxppc-dev
Cc: Sourabh Jain, Aditya Gupta, Daniel Axtens, Hari Bathini,
Madhavan Srinivasan, Mahesh Salgaonkar, Michael Ellerman,
Ritesh Harjani (IBM), Shivang Upadhyay, Venkat Rao Bagalkote,
Aboorva Devarajan
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
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH v2 2/2] powerpc/vmx: avoid KASAN instrumentation in enter_vmx_ops() for kexec
2026-04-03 19:01 ` [PATCH v2 2/2] powerpc/vmx: avoid KASAN instrumentation in enter_vmx_ops() for kexec Sourabh Jain
@ 2026-04-04 1:01 ` Ritesh Harjani
2026-04-04 3:21 ` Sourabh Jain
2026-04-06 19:53 ` Aboorva Devarajan
1 sibling, 1 reply; 9+ messages in thread
From: Ritesh Harjani @ 2026-04-04 1:01 UTC (permalink / raw)
To: Sourabh Jain, linuxppc-dev
Cc: Sourabh Jain, Aditya Gupta, Daniel Axtens, Hari Bathini,
Madhavan Srinivasan, Mahesh Salgaonkar, Michael Ellerman,
Shivang Upadhyay, Venkat Rao Bagalkote, Aboorva Devarajan
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH v2 2/2] powerpc/vmx: avoid KASAN instrumentation in enter_vmx_ops() for kexec
2026-04-04 1:01 ` Ritesh Harjani
@ 2026-04-04 3:21 ` Sourabh Jain
0 siblings, 0 replies; 9+ messages in thread
From: Sourabh Jain @ 2026-04-04 3:21 UTC (permalink / raw)
To: Ritesh Harjani (IBM), linuxppc-dev
Cc: Aditya Gupta, Daniel Axtens, Hari Bathini, Madhavan Srinivasan,
Mahesh Salgaonkar, Michael Ellerman, Shivang Upadhyay,
Venkat Rao Bagalkote, Aboorva Devarajan
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2 2/2] powerpc/vmx: avoid KASAN instrumentation in enter_vmx_ops() for kexec
2026-04-03 19:01 ` [PATCH v2 2/2] powerpc/vmx: avoid KASAN instrumentation in enter_vmx_ops() for kexec Sourabh Jain
2026-04-04 1:01 ` Ritesh Harjani
@ 2026-04-06 19:53 ` Aboorva Devarajan
2026-04-07 5:57 ` Sourabh Jain
1 sibling, 1 reply; 9+ messages in thread
From: Aboorva Devarajan @ 2026-04-06 19:53 UTC (permalink / raw)
To: Sourabh Jain, linuxppc-dev
Cc: Aditya Gupta, Daniel Axtens, Hari Bathini, Madhavan Srinivasan,
Mahesh Salgaonkar, Michael Ellerman, Ritesh Harjani (IBM),
Shivang Upadhyay, Venkat Rao Bagalkote
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH v2 2/2] powerpc/vmx: avoid KASAN instrumentation in enter_vmx_ops() for kexec
2026-04-06 19:53 ` Aboorva Devarajan
@ 2026-04-07 5:57 ` Sourabh Jain
0 siblings, 0 replies; 9+ messages in thread
From: Sourabh Jain @ 2026-04-07 5:57 UTC (permalink / raw)
To: Aboorva Devarajan, linuxppc-dev
Cc: Aditya Gupta, Daniel Axtens, Hari Bathini, Madhavan Srinivasan,
Mahesh Salgaonkar, Michael Ellerman, Ritesh Harjani (IBM),
Shivang Upadhyay, Venkat Rao Bagalkote
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o
2026-04-03 19:01 [PATCH v2 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o Sourabh Jain
2026-04-03 19:01 ` [PATCH v2 2/2] powerpc/vmx: avoid KASAN instrumentation in enter_vmx_ops() for kexec Sourabh Jain
@ 2026-04-04 0:57 ` Ritesh Harjani
2026-04-04 3:20 ` Sourabh Jain
2026-04-06 19:55 ` Aboorva Devarajan
2 siblings, 1 reply; 9+ messages in thread
From: Ritesh Harjani @ 2026-04-04 0:57 UTC (permalink / raw)
To: Sourabh Jain, linuxppc-dev
Cc: Sourabh Jain, Venkat Rao Bagalkote, Aboorva Devarajan,
Aditya Gupta, Daniel Axtens, Hari Bathini, Madhavan Srinivasan,
Michael Ellerman, Shivang Upadhyay, Mahesh Salgaonkar
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH v2 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o
2026-04-04 0:57 ` [PATCH v2 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o Ritesh Harjani
@ 2026-04-04 3:20 ` Sourabh Jain
0 siblings, 0 replies; 9+ messages in thread
From: Sourabh Jain @ 2026-04-04 3:20 UTC (permalink / raw)
To: Ritesh Harjani (IBM), linuxppc-dev
Cc: Venkat Rao Bagalkote, Aboorva Devarajan, Aditya Gupta,
Daniel Axtens, Hari Bathini, Madhavan Srinivasan,
Michael Ellerman, Shivang Upadhyay, Mahesh Salgaonkar
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o
2026-04-03 19:01 [PATCH v2 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o Sourabh Jain
2026-04-03 19:01 ` [PATCH v2 2/2] powerpc/vmx: avoid KASAN instrumentation in enter_vmx_ops() for kexec Sourabh Jain
2026-04-04 0:57 ` [PATCH v2 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o Ritesh Harjani
@ 2026-04-06 19:55 ` Aboorva Devarajan
2 siblings, 0 replies; 9+ messages in thread
From: Aboorva Devarajan @ 2026-04-06 19:55 UTC (permalink / raw)
To: Sourabh Jain, linuxppc-dev
Cc: Venkat Rao Bagalkote, Aditya Gupta, Daniel Axtens, Hari Bathini,
Madhavan Srinivasan, Michael Ellerman, Shivang Upadhyay,
Ritesh Harjani (IBM), Mahesh Salgaonkar, aboorvad
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
^ permalink raw reply [flat|nested] 9+ messages in thread