From: Shrikanth Hegde <sshegde@linux.ibm.com>
To: Sayali Patil <sayalip@linux.ibm.com>,
linuxppc-dev@lists.ozlabs.org, maddy@linux.ibm.com
Cc: linux-kernel@vger.kernel.org,
Ritesh Harjani <ritesh.list@gmail.com>,
Mahesh Salgaonkar <mahesh@linux.ibm.com>,
chleroy@kernel.org
Subject: Re: [PATCH 1/3] powerpc/time: remove preempt_disable/enable from arch_irq_work_raise()
Date: Thu, 7 May 2026 19:06:58 +0530 [thread overview]
Message-ID: <02b09dd2-abb4-4df6-9ad3-74812f34cd60@linux.ibm.com> (raw)
In-Reply-To: <a64fa7d86da51f78743bee26e16ae155c43016c7.1778057685.git.sayalip@linux.ibm.com>
On 5/6/26 2:36 PM, Sayali Patil wrote:
> A kernel panic is observed when handling machine check exceptions from
> real mode.
>
> BUG: Unable to handle kernel data access on read at 0xc00000006be21300
> Oops: Kernel access of bad area, sig: 11 [#1]
> NIP [c000000000029e40] arch_irq_work_raise+0x10/0x70
> LR [c00000000003ffc8] machine_check_queue_event+0xa8/0x150
> Call Trace:
> [c0000000179d3c70] [c00000000003ff64] machine_check_queue_event+0x44/0x150
> [c0000000179d3d30] [c0000000000084e0] machine_check_early_common+0x1f0/0x2c0
>
> The crash occurs because arch_irq_work_raise() calls preempt_disable()
> from machine check exception (MCE) handlers running in real mode. In
> this context, accessing the preempt_count can fault, leading to the panic.
>
> The preempt_disable()/preempt_enable() pair in arch_irq_work_raise()
> was originally added by commit 0fe1ac48bef0 ("powerpc/perf_event: Fix
> oops due to perf_event_do_pending call") to avoid races while raising
> irq work from exception context.
>
> Later, commit 471ba0e686cb ("irq_work: Do not raise an IPI when
> queueing work on the local CPU") added preemption protection in
> irq_work_queue() path, while commit 20b876918c06 ("irq_work: Use per
> cpu atomics instead of regular atomics") added equivalent
> protection in irq_work_queue_on() before reaching arch_irq_work_raise():
>
> irq_work_queue() / irq_work_queue_on()
> -> preempt_disable()
> -> __irq_work_queue_local()
> -> irq_work_raise()
> -> arch_irq_work_raise()
>
> As a result, callers other than mce_irq_work_raise() already execute
> with preemption disabled, making the additional
> preempt_disable()/preempt_enable() pair in arch_irq_work_raise()
> redundant.
>
> Remove it to avoid accessing preempt_count from real mode context.
I assume interrupt is disabled here. So it should be functionally safe
to remove it.
>
> Fixes: cc15ff327569 ("powerpc/mce: Avoid using irq_work_queue() in realmode")
> Suggested-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> Signed-off-by: Sayali Patil <sayalip@linux.ibm.com>
> ---
> arch/powerpc/kernel/time.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
> index 4bbeb8644d3d..a99eb43f6ce9 100644
> --- a/arch/powerpc/kernel/time.c
> +++ b/arch/powerpc/kernel/time.c
> @@ -471,10 +471,8 @@ void arch_irq_work_raise(void)
Could you please add a comment for the function that it expects to
be called with preemption_disabled?
> * which could get tangled up if we're messing with the same state
> * here.
> */
> - preempt_disable();
> set_irq_work_pending_flag();
> set_dec(1);
> - preempt_enable();
> }
>
> static void set_dec_or_work(u64 val)
Acked-by: Shrikanth Hegde <sshegde@linux.ibm.com>
next prev parent reply other threads:[~2026-05-07 13:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-06 9:06 [PATCH 0/3] MCE robustness fixes and LKDTM powerpc enhancements Sayali Patil
2026-05-06 9:06 ` [PATCH 1/3] powerpc/time: remove preempt_disable/enable from arch_irq_work_raise() Sayali Patil
2026-05-07 13:36 ` Shrikanth Hegde [this message]
2026-05-13 4:30 ` Ritesh Harjani
2026-05-13 5:35 ` Shrikanth Hegde
2026-05-06 9:06 ` [PATCH 2/3] lkdtm/powerpc: add isync after slbmte to enforce SLB update ordering Sayali Patil
2026-05-06 9:06 ` [PATCH 3/3] lkdtm/powerpc: add PPC_RADIX_TLBIEL test for radix MCE validation Sayali Patil
2026-05-13 7:08 ` [PATCH 0/3] MCE robustness fixes and LKDTM powerpc enhancements Sayali Patil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=02b09dd2-abb4-4df6-9ad3-74812f34cd60@linux.ibm.com \
--to=sshegde@linux.ibm.com \
--cc=chleroy@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mahesh@linux.ibm.com \
--cc=ritesh.list@gmail.com \
--cc=sayalip@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.