All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Xie Yuanbin" <xieyuanbin1@huawei.com>
Cc: linux-rt-devel@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] ARM: enable interrupts when unhandled user faults are triggered
Date: Mon, 29 Jun 2026 12:51:16 +0000	[thread overview]
Message-ID: <20260629125117.34C4D1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260629123349.134224-1-xieyuanbin1@huawei.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Missing interrupt enablement in baddataabort() before sending signals, causing a PREEMPT_RT sleeping-while-atomic BUG.
--

commit c514933dc1b8809c06e2a04abca8d68edc5cd623
Author: Xie Yuanbin <xieyuanbin1@huawei.com>

ARM: enable interrupts when unhandled user faults are triggered

This commit enables interrupts in do_DataAbort() and do_PrefetchAbort()
when unhandled user faults are triggered. This resolves an issue on
PREEMPT_RT where calling force_sig_fault() with interrupts disabled
would cause problems, as PREEMPT_RT requires interrupts to be enabled
when sending signals.

> diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
> index e62cc4be5adf6..c686775035325 100644
> --- a/arch/arm/mm/fault.c
> +++ b/arch/arm/mm/fault.c
> @@ -633,6 +633,9 @@ do_DataAbort(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
>  	if (!inf->fn(addr, fsr & ~FSR_LNX_PF, regs))
>  		return;
>  
> +	if (likely(user_mode(regs)))
> +		local_irq_enable();
> +

[Severity: Critical]
This is a pre-existing issue, but does a similar fix need to be applied
to baddataabort() in arch/arm/kernel/traps.c?

If a user-space program executes an unsupported data access instruction on
architectures using v4t_late_abort (like ARM720T or ARM7TDMI), it raises
a data abort exception and enters __dabt_usr with interrupts disabled.

Execution can proceed to v4t_late_abort(), and if instruction decode
fails, it branches to baddataabort():

arch/arm/mm/abort-lv4t.S:v4t_late_abort()
    .data_unknown:
        mov r0, r4
        mov r1, r8
        b   baddataabort

baddataabort() then calls arm_notify_die() which eventually calls
force_sig_fault():

arch/arm/kernel/traps.c:baddataabort()
    arm_notify_die("unknown data abort code", regs,
                   SIGILL, ILL_ILLOPC, (void __user *)addr, instr, 0);

Because baddataabort() lacks the local_irq_enable() being added here in
do_DataAbort(), interrupts remain disabled during signal delivery. Could
this allow an unprivileged local user to trigger this path and cause a
sleeping-while-atomic panic on PREEMPT_RT?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629123349.134224-1-xieyuanbin1@huawei.com?part=1

  parent reply	other threads:[~2026-06-29 12:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-29 12:33 [PATCH v2] ARM: enable interrupts when unhandled user faults are triggered Xie Yuanbin
2026-06-29 12:48 ` Xie Yuanbin
2026-06-29 13:12   ` Sebastian Andrzej Siewior
2026-06-29 12:51 ` sashiko-bot [this message]
2026-06-29 13:14 ` Sebastian Andrzej Siewior
2026-06-30 22:49 ` Linus Walleij

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=20260629125117.34C4D1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-devel@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=xieyuanbin1@huawei.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.