The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Xie Yuanbin <xieyuanbin1@huawei.com>
Cc: linux@armlinux.org.uk, clrkwllms@kernel.org, rostedt@goodmis.org,
	rmk+kernel@armlinux.org.uk, linusw@kernel.org, arnd@arndb.de,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev,
	liaohua4@huawei.com, lilinjie8@huawei.com
Subject: Re: [PATCH] ARM: enable interrupts when arm_notify_die() is handling user mode errors
Date: Thu, 25 Jun 2026 10:50:34 +0200	[thread overview]
Message-ID: <20260625085034.tvyGSmaP@linutronix.de> (raw)
In-Reply-To: <20260625073522.182503-1-xieyuanbin1@huawei.com>

On 2026-06-25 15:35:22 [+0800], Xie Yuanbin wrote:
> For lastest linux-next kernel, with default multi_v7_defconfig, and
> setting CONFIG_PREEMPT_RT=y, CONFIG_DEBUG_ATOMIC_SLEEP=y, and
> CONFIG_PERF_EVENTS=n. When the user program executes bkpt
> instruction, the following WARN will be triggered:
> ```log
> [    3.677825] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
> [    3.678002] in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 84, name: test
> [    3.678036] preempt_count: 0, expected: 0
> [    3.678078] RCU nest depth: 0, expected: 0
> [    3.678864] CPU: 0 UID: 0 PID: 84 Comm: test Tainted: G        W           7.1.0-next-20260623 #45 PREEMPT_RT
> [    3.679067] Tainted: [W]=WARN
> [    3.679088] Hardware name: Generic DT based system
> [    3.679198] Call trace:
> [    3.679695]  unwind_backtrace from show_stack+0x10/0x14
> [    3.680363]  show_stack from dump_stack_lvl+0x50/0x5c
> [    3.680377]  dump_stack_lvl from __might_resched+0x160/0x174
> [    3.680393]  __might_resched from rt_spin_lock+0x38/0x138
> [    3.680425]  rt_spin_lock from force_sig_info_to_task+0x1c/0x11c
> [    3.680438]  force_sig_info_to_task from force_sig_fault+0x44/0x64
> [    3.680450]  force_sig_fault from do_PrefetchAbort+0x94/0x9c
> [    3.680461]  do_PrefetchAbort from ret_from_exception+0x0/0x20
> [    3.680513] Exception stack(0xf0ab5fb0 to 0xf0ab5ff8)
> [    3.680653] 5fa0:                                     00000000 bed32e94 bed32e9c 00037954
> [    3.680672] 5fc0: 00000002 00000001 bed32e94 0009d590 00000000 bed32e9c 00000002 00000000
> [    3.680682] 5fe0: bed32d48 bed32d38 00037a00 00037958 60000010 ffffffff
> ```

I don't think this required information as it is obvious. At the very
least you could trim it the needed parts if considered needed.

> When PREEMPT_RT is enabled, force_sig_info() requires interrupts to be
> enabled. Enable interrupts when arm_notify_die() is handling user mode
> errors to fix the issue.
> 
> Fixes: c6e61c06d606 ("ARM: 9463/1: Allow to enable RT")
> 
> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Cc: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> Signed-off-by: Xie Yuanbin <xieyuanbin1@huawei.com>

So I did test the 32bit case on arm64 while testing/ backporting the
breakpoint handling there but apparently did not try it on real
arm32.

For "asm("BKPT #0");" the SIGTRAP is not raised instead I get just
| 8<--- cut here ---
| Unhandled prefetch abort: debug event (0x222) at 0x00000000

on the kernel side and a "Bus error" on userland side.

So
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

for this but actual breakpoint handling might be broken or is it just
me? But then your stack trace looks like mine so :/

Sebastian

  reply	other threads:[~2026-06-25  8:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-25  7:35 [PATCH] ARM: enable interrupts when arm_notify_die() is handling user mode errors Xie Yuanbin
2026-06-25  8:50 ` Sebastian Andrzej Siewior [this message]
2026-06-25  9:05   ` Russell King
2026-06-25  9:30     ` Sebastian Andrzej Siewior
2026-06-25 10:20       ` Russell King
2026-06-25 12:08         ` Sebastian Andrzej Siewior
2026-06-25 10:00 ` Xie Yuanbin
2026-06-25 10:23   ` Russell King
2026-06-25 12:26     ` Xie Yuanbin
2026-06-25 15:21       ` Sebastian Andrzej Siewior
2026-06-26  8:29         ` Xie Yuanbin

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=20260625085034.tvyGSmaP@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=arnd@arndb.de \
    --cc=clrkwllms@kernel.org \
    --cc=liaohua4@huawei.com \
    --cc=lilinjie8@huawei.com \
    --cc=linusw@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-devel@lists.linux.dev \
    --cc=linux@armlinux.org.uk \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=rostedt@goodmis.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox