Re: [PATCH v4 1/2] ARM: mm: fault: Enable interrupts before invoking __do_user_fault()

Russell King (Oracle)
2026-01-16T20:01:28Z

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!