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

On Fri, Jan 16, 2026 at 08:07:52PM +0000, Russell King (Oracle) wrote:

On Fri, Jan 16, 2026 at 08:01:20PM +0000, Russell King (Oracle) wrote:

quoted

On Fri, Jan 16, 2026 at 07:12:01PM +0100, Sebastian Andrzej Siewior wrote:

quoted

On 2026-01-16 17:33:48 [+0000], Russell King (Oracle) wrote:

quoted

On Fri, Jan 16, 2026 at 06:00:40PM +0100, Sebastian Andrzej Siewior wrote:

quoted

From: "Yadi.hu" <redacted>

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.

Oh, and, as I've said on netdev recently, I have lots of patches. I
don't have time to push all patches all the time. Those that I think
are the highest priority get the attention - so if something goes
quiet, the patches don't get progressed (because something else has
taken over.)

I haven't published these yet to my external git tree because they're
currently on top of my raw private "development" branch containing...

$ git lg origin..rmk | wc -l
473

many of those behind those I mentioned above. At some point I need to
move them to their own separate branch, or to the "misc" branch after
sending them to the mailing list... but the latter means spending time
writing a covering message summarising the changes, and the key thing
is "time".

I've wasted almost all of today running a bisect for a stmmac issue that
takes out my _entire_ network at home. It's wasted because what I
thought was a good commit turns out, on re-testing, to have been bad,
and right now I have no idea what a good commit is, and whether that
even exists before the platform support was merged.

Sorry for a third reply... yesterday I started at about 10am, finished
at 2am last night chasing a different stmmac regression.

Yea, if there was more time, then I could push all the patches I have,
but I don't, and the above patches were generated back when we were
discussing the issue last time.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!