[PATCH v4 0/2] ARM: Remaining PREEMPT_RT bits

[PATCH v4 0/2] ARM: Remaining PREEMPT_RT bits

[Sebastian Andrzej Siewior]

this is the last batch I have to enable PREEMPT_RT on the ARM
architecture. It is just sending a signal with disabled interrupts and finally
enabling PREEMPT_RT on ARM.

Is this okay?

v3…v4: https://lore.kernel.org/all/20251110145555.2555055-1-bigeasy@linutronix.de
  - Dropped applied patches
  - Rebased the remaining one on top of the recent fault handler and branch
    predictor fixes.

v2…v3: https://lore.kernel.org/all/20251103101545.760243-1-bigeasy@linutronix.de
  - Collected tags.

v1…v2: https://lore.kernel.org/all/20251029155918.503060-1-bigeasy@linutronix.de
  - Allow to enable jump-labels on UP. The UP build does not involve
    stop_machine(). Reworked by Arnd.

  - Instead of forbidding HAVE_GUP_FAST with HIGHPTE enabled just
    disable HIGHPTE on PREEMPT_RT. As Arnd explained, HIGHPTE is rarely
    needed.

  - Don't let ARCH_SUPPORTS_RT depend on HAVE_POSIX_CPU_TIMERS_TASK_WORK
    which in turn depends on !KVM. Since KVM has been removed from ARM
    it is sufficient to unconditionally allow ARCH_SUPPORTS_RT. Noted
    by Arnd.

Sebastian Andrzej Siewior (1):
  ARM: Allow to enable RT

Yadi.hu (1):
  ARM: mm: fault: Enable interrupts before invoking __do_user_fault()

 arch/arm/Kconfig    | 1 +
 arch/arm/mm/fault.c | 4 ++++
 2 files changed, 5 insertions(+)

-- 
2.51.0

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

[Sebastian Andrzej Siewior]

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.

[bigeasy: Initial patch/ report by Yadi. Maintained the patch and redid
          the patch description since]

Signed-off-by: Yadi.hu <yadi.hu@windriver.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 arch/arm/mm/fault.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index ed4330cc3f4e6..3f1c73269c126 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -270,6 +270,7 @@ do_kernel_address_page_fault(struct mm_struct *mm, unsigned long addr,
 		 * while interrupts are still disabled, then send a SIGSEGV.
 		 */
 		harden_branch_predictor();
+		local_irq_enable();
 		__do_user_fault(addr, fsr, SIGSEGV, SEGV_MAPERR, regs);
 	} else {
 		/*
@@ -592,6 +593,9 @@ do_sect_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
 	if (addr >= TASK_SIZE && user_mode(regs))
 		harden_branch_predictor();
 
+	if (interrupts_enabled(regs))
+		local_irq_enable();
+
 	do_bad_area(addr, fsr, regs);
 
 	return 0;
-- 
2.51.0

[PATCH v4 2/2] ARM: Allow to enable RT

[Sebastian Andrzej Siewior]

All known issues have been adressed.
Allow to select RT.

Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 arch/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index fa83c040ee2d4..547df4161e0dd 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -41,6 +41,7 @@ config ARM
 	select ARCH_SUPPORTS_CFI
 	select ARCH_SUPPORTS_HUGETLBFS if ARM_LPAE
 	select ARCH_SUPPORTS_PER_VMA_LOCK
+	select ARCH_SUPPORTS_RT
 	select ARCH_USE_BUILTIN_BSWAP
 	select ARCH_USE_CMPXCHG_LOCKREF
 	select ARCH_USE_MEMTEST
-- 
2.51.0

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

[Russell King (Oracle)]

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.

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

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

[Sebastian Andrzej Siewior]

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

Sebastian

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

[Russell King (Oracle)]

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!

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

[Russell King (Oracle)]

On Fri, Jan 16, 2026 at 08:01:20PM +0000, Russell King (Oracle) wrote:
> 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.

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.

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

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

[Russell King (Oracle)]

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:
> > 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.
> 
> 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!

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

[Sebastian Andrzej Siewior]

On 2026-01-16 20:09:43 [+0000], Russell King (Oracle) wrote:
> > 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.

No worries. Is your tree rmk tree public so I could pull those and test?
Do you want me to review any of those?

Sebastian