From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: linux-arm-kernel@lists.infradead.org,
linux-rt-devel@lists.linux.dev, Arnd Bergmann <arnd@arndb.de>,
Linus Walleij <linus.walleij@linaro.org>,
"Yadi.hu" <yadi.hu@windriver.com>, Bryan Brattlof <bb@ti.com>
Subject: Re: [PATCH v4 1/2] ARM: mm: fault: Enable interrupts before invoking __do_user_fault()
Date: Fri, 16 Jan 2026 20:01:19 +0000 [thread overview]
Message-ID: <aWqZDwxUtaE1yP28@shell.armlinux.org.uk> (raw)
In-Reply-To: <20260116181201.v-z31XJY@linutronix.de>
On Fri, Jan 16, 2026 at 07:12:01PM +0100, Sebastian Andrzej Siewior wrote:
> On 2026-01-16 17:33:48 [+0000], Russell King (Oracle) wrote:
> > On Fri, Jan 16, 2026 at 06:00:40PM +0100, Sebastian Andrzej Siewior wrote:
> > > From: "Yadi.hu" <yadi.hu@windriver.com>
> > >
> > > A page fault from userland for a kernel address originates from from
> > > do_sect_fault() (!LPAE) or do_page_fault() and ends in __do_user_fault()
> > > by sending a signal.
> > >
> > > Sending a signal requires to acquire sighand_struct::siglock which is a
> > > spinlock_t. On PREEMPT_RT spinlock_t becomes a sleeping spin lock which
> > > requires interrupts to be enabled. Since the calling context is user
> > > land, interrupts must have been enabled so it is fine to enable them in
> > > this case.
> > >
> > > Enable interrupts in do_kernel_address_page_fault() unconditional in the
> > > user_mode case().
> > > Enable interrupts in do_sect_fault() if they were previously enabled.
> >
> > Do you need any of this? __do_user_fault() now calls
> > local_irq_enable() as almost the first thing it does.
>
> Different path(s):
>
> LPAE
> | BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
> | in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 639, name: arm-segfault
> | preempt_count: 0, expected: 0
> | RCU nest depth: 0, expected: 0
> | CPU: 0 UID: 0 PID: 639 Comm: arm-segfault3 Tainted: G W 6.19.0-rc5-dirty #7 PREEMPT_RT
> | Tainted: [W]=WARN
> | Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022
> | Call trace:
> | unwind_backtrace from show_stack+0x18/0x1c
> | show_stack from dump_stack_lvl+0x34/0x44
> | dump_stack_lvl from __might_resched+0x180/0x1c0
> | __might_resched from rt_spin_lock+0x3c/0x1f0
> | rt_spin_lock from force_sig_info_to_task+0x24/0x184
> | force_sig_info_to_task from force_sig_fault+0x50/0x74
> | force_sig_fault from do_kernel_address_page_fault+0xa8/0xb4
> | do_kernel_address_page_fault from do_DataAbort+0x38/0xac
> | do_DataAbort from __dabt_usr+0x50/0x60
>
> !LPAE
> | BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
> | in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 622, name: arm-segfault
> | preempt_count: 0, expected: 0
> | RCU nest depth: 0, expected: 0
> | CPU: 0 UID: 0 PID: 622 Comm: arm-segfault Tainted: G W 6.19.0-rc5-dirty #8 PREEMPT_RT
> | Tainted: [W]=WARN
> | Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022
> | Call trace:
> | unwind_backtrace from show_stack+0x18/0x1c
> | show_stack from dump_stack_lvl+0x34/0x44
> | dump_stack_lvl from __might_resched+0x180/0x1c0
> | __might_resched from rt_spin_lock+0x3c/0x1f0
> | rt_spin_lock from force_sig_info_to_task+0x24/0x184
> | force_sig_info_to_task from force_sig_fault+0x50/0x74
> | force_sig_fault from do_sect_fault+0x30/0x80
> | do_sect_fault from do_DataAbort+0x44/0xb8
> | do_DataAbort from __dabt_usr+0x50/0x60
Right, because I haven't pushed all the patches out. What was pushed out
was the basic set of fixes during the last merge window:
fd2dee1c6e22 ARM: fix branch predictor hardening (fixes)
7733bc7d299d ARM: fix hash_name() fault
40b466db1dff ARM: allow __do_kernel_fault() to report execution of memory faults
dea20281ac88 ARM: group is_permission_fault() with is_translation_fault()
edb924a7211c ARM: 9464/1: fix input-only operand modification in load_unaligned_zeropad()
which were sent out on the 8th December, but I still have these:
1055c9d604f9 ARM: provide individual is_translation_fault() and is_permission_fault()
47ce12a37f82 ARM: move FSR fault status definitions before fsr_fs()
eefbf2e97ad5 ARM: use BIT() and GENMASK() for fault status register fields
5f1e55bed37f ARM: move is_permission_fault() and is_translation_fault() to fault.h
ad1c1212ae15 ARM: move vmalloc() lazy-page table population
92442d814d99 ARM: ensure interrupts are enabled in __do_user_fault()
and, because they weren't fixes, it would've been inappropriate to
post these. However, I was on vacation from the 11th December through
to the 2nd January, had the madness of the huge email mountain, and
been working on stmmac and internal work issues since, I've not had any
time to look at anything else.
However, these changes will negate the need for your patch 1.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2026-01-16 20:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-16 17:00 [PATCH v4 0/2] ARM: Remaining PREEMPT_RT bits Sebastian Andrzej Siewior
2026-01-16 17:00 ` [PATCH v4 1/2] ARM: mm: fault: Enable interrupts before invoking __do_user_fault() Sebastian Andrzej Siewior
2026-01-16 17:33 ` Russell King (Oracle)
2026-01-16 18:12 ` Sebastian Andrzej Siewior
2026-01-16 20:01 ` Russell King (Oracle) [this message]
2026-01-16 20:07 ` Russell King (Oracle)
2026-01-16 20:09 ` Russell King (Oracle)
2026-01-16 20:30 ` Sebastian Andrzej Siewior
2026-01-16 17:00 ` [PATCH v4 2/2] ARM: Allow to enable RT Sebastian Andrzej Siewior
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=aWqZDwxUtaE1yP28@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=arnd@arndb.de \
--cc=bb@ti.com \
--cc=bigeasy@linutronix.de \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=yadi.hu@windriver.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