[PATCH 0/5] ARM: Remaining PREEMPT_RT bits

[PATCH 0/5] ARM: Remaining PREEMPT_RT bits

[Sebastian Andrzej Siewior]

Hi,

this is the last batch I have to enable PREEMPT_RT on the ARM
architecture.
Last time I posted them there was some discussion about making the
branch predictor hardening worse. I redid it hoping it improved now and
does not make it worse.

Sebastian Andrzej Siewior (3):
  ARM: mm: fault: Move harden_branch_predictor() before interrupts are
    enabled
  arm: Disable FAST_GUP on PREEMPT_RT if HIGHPTE is also enabled.
  ARM: Allow to enable RT

Thomas Gleixner (1):
  arm: Disable jump-label on PREEMPT_RT.

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

 arch/arm/Kconfig    |  6 ++++--
 arch/arm/mm/fault.c | 16 ++++++++++------
 2 files changed, 14 insertions(+), 8 deletions(-)

-- 
2.51.0

[PATCH 1/5] ARM: mm: fault: Move harden_branch_predictor() before interrupts are enabled

[Sebastian Andrzej Siewior]

In the LPAE case, interrupts are enabled early in do_page_fault(). If
the user attempts to access a pointer > TASK_SIZE then is invoked
harden_branch_predictor(). The function will complain that CPU migration
is enabled due to its smp_processor_id() usage.

The intention is invoke harden_branch_predictor() on the CPU which
triggered the page fault. It is only invoked for user access of pointer
> TASK_SIZE. This always generate a fault for the user because this area
is restricted to the kernel.

Move the invocation of harden_branch_predictor() up in the call chain to
the two callers do_bad_area() and do_page_fault().
Invoke it if the user accesses the >= TASK_SIZE area.

Fixes: f5fe12b1eaee2 ("ARM: spectre-v2: harden user aborts in kernel space")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 arch/arm/mm/fault.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index 2bc828a1940c0..5d28c28e877c1 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -183,9 +183,6 @@ __do_user_fault(unsigned long addr, unsigned int fsr, unsigned int sig,
 {
 	struct task_struct *tsk = current;
 
-	if (addr > TASK_SIZE)
-		harden_branch_predictor();
-
 #ifdef CONFIG_DEBUG_USER
 	if (((user_debug & UDBG_SEGV) && (sig == SIGSEGV)) ||
 	    ((user_debug & UDBG_BUS)  && (sig == SIGBUS))) {
@@ -218,10 +215,13 @@ void do_bad_area(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
 	 * If we are in kernel mode at this point, we
 	 * have no context to handle this fault with.
 	 */
-	if (user_mode(regs))
+	if (user_mode(regs)) {
+		if (addr >= TASK_SIZE)
+			harden_branch_predictor();
 		__do_user_fault(addr, fsr, SIGSEGV, SEGV_MAPERR, regs);
-	else
+	} else {
 		__do_kernel_fault(mm, addr, fsr, regs);
+	}
 }
 
 #ifdef CONFIG_MMU
@@ -274,8 +274,11 @@ do_page_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
 
 
 	/* Enable interrupts if they were enabled in the parent context. */
-	if (interrupts_enabled(regs))
+	if (interrupts_enabled(regs)) {
+		if (user_mode(regs) && addr >= TASK_SIZE)
+			harden_branch_predictor();
 		local_irq_enable();
+	}
 
 	/*
 	 * If we're in an interrupt or have no user
-- 
2.51.0

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

[Sebastian Andrzej Siewior]

From: "Yadi.hu" <yadi.hu@windriver.com>

In the !LPAE case __do_user_fault() is invoked from do_bad_area(). If a
user pointer cause the page fault then a signal is sent.

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_bad_area() before invoking __do_user_fault().

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

Signed-off-by: Yadi.hu <yadi.hu@windriver.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 arch/arm/mm/fault.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index 5d28c28e877c1..ad58c1e22a5f9 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -218,6 +218,7 @@ void do_bad_area(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
 	if (user_mode(regs)) {
 		if (addr >= TASK_SIZE)
 			harden_branch_predictor();
+		local_irq_enable();
 		__do_user_fault(addr, fsr, SIGSEGV, SEGV_MAPERR, regs);
 	} else {
 		__do_kernel_fault(mm, addr, fsr, regs);
-- 
2.51.0

[PATCH 3/5] ARM: Disable FAST_GUP on PREEMPT_RT if HIGHPTE is also enabled.

[Sebastian Andrzej Siewior]

gup_pgd_range() is invoked with disabled interrupts and invokes
__kmap_local_page_prot() via pte_offset_map(), gup_p4d_range().
With HIGHPTE enabled, __kmap_local_page_prot() invokes kmap_high_get()
which uses a spinlock_t via lock_kmap_any(). This leads to an
sleeping-while-atomic error on PREEMPT_RT because spinlock_t becomes a
sleeping spin lock and must not be acquired in atomic context.

The loop in map_new_virtual() uses wait_queue_head_t for wake up which
also is using a spinlock_t.

Limit HAVE_FAST_GUP additionally to remain disabled on PREEMPT_RT with
HIGHPTE enabled.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 arch/arm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2e3f93b690f47..864a14a434b08 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -105,7 +105,7 @@ config ARM
 	select HAVE_DYNAMIC_FTRACE_WITH_REGS if HAVE_DYNAMIC_FTRACE
 	select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && MMU
 	select HAVE_EXIT_THREAD
-	select HAVE_GUP_FAST if ARM_LPAE
+	select HAVE_GUP_FAST if ARM_LPAE && !(PREEMPT_RT && HIGHPTE)
 	select HAVE_FUNCTION_ERROR_INJECTION
 	select HAVE_FUNCTION_GRAPH_TRACER
 	select HAVE_FUNCTION_GRAPH_FREGS
-- 
2.51.0

Re: [PATCH 3/5] ARM: Disable FAST_GUP on PREEMPT_RT if HIGHPTE is also enabled.

[Arnd Bergmann]

On Wed, Oct 29, 2025, at 16:59, Sebastian Andrzej Siewior wrote:
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -105,7 +105,7 @@ config ARM
>  	select HAVE_DYNAMIC_FTRACE_WITH_REGS if HAVE_DYNAMIC_FTRACE
>  	select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && MMU
>  	select HAVE_EXIT_THREAD
> -	select HAVE_GUP_FAST if ARM_LPAE
> +	select HAVE_GUP_FAST if ARM_LPAE && !(PREEMPT_RT && HIGHPTE)
>  	select HAVE_FUNCTION_ERROR_INJECTION
>  	select HAVE_FUNCTION_GRAPH_TRACER
>  	select HAVE_FUNCTION_GRAPH_FREGS

I would still prefer the version I posted previous at

https://lore.kernel.org/all/20241210160556.2341497-3-arnd@kernel.org/

disabling HIGHPTE when PREEMPT_RT is enabled.

     Arnd

Re: [PATCH 3/5] ARM: Disable FAST_GUP on PREEMPT_RT if HIGHPTE is also enabled.

[Sebastian Andrzej Siewior]

On 2025-10-30 16:15:42 [+0100], Arnd Bergmann wrote:
> On Wed, Oct 29, 2025, at 16:59, Sebastian Andrzej Siewior wrote:
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -105,7 +105,7 @@ config ARM
> >  	select HAVE_DYNAMIC_FTRACE_WITH_REGS if HAVE_DYNAMIC_FTRACE
> >  	select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && MMU
> >  	select HAVE_EXIT_THREAD
> > -	select HAVE_GUP_FAST if ARM_LPAE
> > +	select HAVE_GUP_FAST if ARM_LPAE && !(PREEMPT_RT && HIGHPTE)
> >  	select HAVE_FUNCTION_ERROR_INJECTION
> >  	select HAVE_FUNCTION_GRAPH_TRACER
> >  	select HAVE_FUNCTION_GRAPH_FREGS
> 
> I would still prefer the version I posted previous at
> 
> https://lore.kernel.org/all/20241210160556.2341497-3-arnd@kernel.org/
> 
> disabling HIGHPTE when PREEMPT_RT is enabled.

I did remember that we shifted something I just wasn't sure what it was.
I will update for v2.

>      Arnd

Sebastian

[PATCH 4/5] ARM: Disable jump-label on PREEMPT_RT.

[Sebastian Andrzej Siewior]

From: Thomas Gleixner <tglx@linutronix.de>

jump-labels are used to efficiently switch between two possible code
paths. To achieve this, stop_machine() is used to keep the CPU in a
known state while the opcode is modified. The usage of stop_machine()
here leads to large latency spikes which can be observed on PREEMPT_RT.

Jump labels may change the target during runtime and are not restricted
to debug or "configuration/ setup" part of a PREEMPT_RT system where
high latencies could be defined as acceptable.

Disable jump-label support on a PREEMPT_RT system.

[bigeasy: Patch description.]

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 arch/arm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 864a14a434b08..99c9b1c320af8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -80,7 +80,7 @@ config ARM
 	select HAS_IOPORT
 	select HAVE_ARCH_AUDITSYSCALL if AEABI && !OABI_COMPAT
 	select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
-	select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
+	select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU && !PREEMPT_RT
 	select HAVE_ARCH_KFENCE if MMU && !XIP_KERNEL
 	select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
 	select HAVE_ARCH_KASAN if MMU && !XIP_KERNEL
-- 
2.51.0

Re: [PATCH 4/5] ARM: Disable jump-label on PREEMPT_RT.

[Xie Yuanbin]

On Wed, 29 Oct 2025 16:59:17 +0100, Thomas Gleixner wrote:
> jump-labels are used to efficiently switch between two possible code
> paths. To achieve this, stop_machine() is used to keep the CPU in a
> known state while the opcode is modified. The usage of stop_machine()
> here leads to large latency spikes which can be observed on PREEMPT_RT.
>
> Jump labels may change the target during runtime and are not restricted
> to debug or "configuration/ setup" part of a PREEMPT_RT system where
> high latencies could be defined as acceptable.
>
> Disable jump-label support on a PREEMPT_RT system.

This sounds like a performance issue rather than a feature issue.
Banning users from using the jump label because of a performance problem
seems like throwing the baby out with the bathwater.
Perhaps we could add a config like CONFIG_ARM_JUMP_LABEL_RT_FORCE that
allows users to select, and inform users in the description about
potential latency.

Xie Yuanbin

Re: [PATCH 4/5] ARM: Disable jump-label on PREEMPT_RT.

[Sebastian Andrzej Siewior]

On 2025-10-30 10:39:59 [+0800], Xie Yuanbin wrote:
> On Wed, 29 Oct 2025 16:59:17 +0100, Thomas Gleixner wrote:
> > jump-labels are used to efficiently switch between two possible code
> > paths. To achieve this, stop_machine() is used to keep the CPU in a
> > known state while the opcode is modified. The usage of stop_machine()
> > here leads to large latency spikes which can be observed on PREEMPT_RT.
> >
> > Jump labels may change the target during runtime and are not restricted
> > to debug or "configuration/ setup" part of a PREEMPT_RT system where
> > high latencies could be defined as acceptable.
> >
> > Disable jump-label support on a PREEMPT_RT system.
> 
> This sounds like a performance issue rather than a feature issue.
> Banning users from using the jump label because of a performance problem
> seems like throwing the baby out with the bathwater.
> Perhaps we could add a config like CONFIG_ARM_JUMP_LABEL_RT_FORCE that
> allows users to select, and inform users in the description about
> potential latency.

It is not a performance issue, it is a latency issue. If the scheduling
latency increases by 300us because of this then the PREEMPT_RT system
becomes worthless.

> Xie Yuanbin

Sebastian

Re: [PATCH 4/5] ARM: Disable jump-label on PREEMPT_RT.

[Xie Yuanbin]

On Thu, 30 Oct 2025 08:23:39 +0100, Sebastian Andrzej Siewior wrote:
> It is not a performance issue, it is a latency issue. If the scheduling
> latency increases by 300us because of this then the PREEMPT_RT system
> becomes worthless.

I understand what you mean. But this delay only occurs when the static
key is enabled/disabled, right? For users, we can control when to
enable/disable the static key, but it's a real shame if jump labels
aren't available.
Therefore, my personal opinion is that informing users that JUMP_LABEL
might cause unexpected delays, rather than disabling it, would be more
appropriate. ;)

Xie Yuanbin

Re: [PATCH 4/5] ARM: Disable jump-label on PREEMPT_RT.

[Sebastian Andrzej Siewior]

On 2025-10-30 15:45:07 [+0800], Xie Yuanbin wrote:
> On Thu, 30 Oct 2025 08:23:39 +0100, Sebastian Andrzej Siewior wrote:
> > It is not a performance issue, it is a latency issue. If the scheduling
> > latency increases by 300us because of this then the PREEMPT_RT system
> > becomes worthless.
> 
> I understand what you mean. But this delay only occurs when the static
> key is enabled/disabled, right? For users, we can control when to
> enable/disable the static key, but it's a real shame if jump labels
> aren't available.
> Therefore, my personal opinion is that informing users that JUMP_LABEL
> might cause unexpected delays, rather than disabling it, would be more
> appropriate. ;)

You can't really control when jump labels are enabled/ disabled. For
instance this happens if you enable/ disable trace points.
Arm64 and X86 replaced the stop_machine() logic with something else that
does not affect latency in that magnitude. If Arm could something
similar then fine but until then I don't see a way around it.
There are other things that are disabled on PREEMPT_RT due to latency
reasons such as transparent huge pages or expedited RCU.

> Xie Yuanbin

Sebastian

Re: [PATCH 4/5] ARM: Disable jump-label on PREEMPT_RT.

[Steven Rostedt]

On Thu, 30 Oct 2025 08:55:58 +0100
Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:

> You can't really control when jump labels are enabled/ disabled. For
> instance this happens if you enable/ disable trace points.
> Arm64 and X86 replaced the stop_machine() logic with something else that
> does not affect latency in that magnitude. If Arm could something
> similar then fine but until then I don't see a way around it.
> There are other things that are disabled on PREEMPT_RT due to latency
> reasons such as transparent huge pages or expedited RCU.

But transparent huge pages and expedited RCU are not user controlled events.

Enabling function tracing was known to cause huge latency for a very long
time and it came from the PREEMPT_RT patch set. Heck, printk use to as well ;-)

Instead, we could print a message to the console stating that a huge
latency has just occurred due to user activation. Similar to what we used
to post when RT Throttling happened (I don't see that message anymore since
dl_server was added :-/).

-- Steve

Re: [PATCH 4/5] ARM: Disable jump-label on PREEMPT_RT.

[Sebastian Andrzej Siewior]

On 2025-10-30 05:46:26 [-0400], Steven Rostedt wrote:
> On Thu, 30 Oct 2025 08:55:58 +0100
> Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> 
> > You can't really control when jump labels are enabled/ disabled. For
> > instance this happens if you enable/ disable trace points.
> > Arm64 and X86 replaced the stop_machine() logic with something else that
> > does not affect latency in that magnitude. If Arm could something
> > similar then fine but until then I don't see a way around it.
> > There are other things that are disabled on PREEMPT_RT due to latency
> > reasons such as transparent huge pages or expedited RCU.
> 
> But transparent huge pages and expedited RCU are not user controlled events.
> 
> Enabling function tracing was known to cause huge latency for a very long
> time and it came from the PREEMPT_RT patch set. Heck, printk use to as well ;-)

trace events were an example and this is used to enable tracing in
production or development to gather information if something is not
working right _or_ on the edge to investigate. A latency spike at this
point would be a timing violation forcing the system into a safe state
an so not allowing further investigations.

I hope I made it clear that using jump-labels at this point is not
doable at this point and a warning does not improve things. Improving
the implementation on ARM as it has been done on ARM64 or X86 is how I
would compare the situation to printk. Not adding a warning at boot
time.

> -- Steve

Sebastian

Re: [PATCH 4/5] ARM: Disable jump-label on PREEMPT_RT.

[Steven Rostedt]

On Thu, 30 Oct 2025 10:56:15 +0100
Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:

> trace events were an example and this is used to enable tracing in
> production or development to gather information if something is not
> working right _or_ on the edge to investigate. A latency spike at this
> point would be a timing violation forcing the system into a safe state
> an so not allowing further investigations.
> 
> I hope I made it clear that using jump-labels at this point is not
> doable at this point and a warning does not improve things. Improving
> the implementation on ARM as it has been done on ARM64 or X86 is how I
> would compare the situation to printk. Not adding a warning at boot
> time.

I wasn't talking about the print being at boot time. But when it gets
enabled (like when RT throttling happened). I wouldn't even do it the first
time it gets enabled, but print a waring when it is activated if the last
time it printed a warning was over a minute ago. Thus, even if it was
already printed, but it didn't cause any noticeable latency, it would print
again when it does.

Thus, if the system goes into a "safe state", it is obvious from the logs
it was caused by a user interaction.

-- Steve

Re: [PATCH 4/5] ARM: Disable jump-label on PREEMPT_RT.

[Russell King (Oracle)]

On Thu, Oct 30, 2025 at 08:55:58AM +0100, Sebastian Andrzej Siewior wrote:
> Arm64 and X86 replaced the stop_machine() logic with something else that
> does not affect latency in that magnitude. If Arm could something
> similar then fine but until then I don't see a way around it.

"If Arm could". For 32-bit, Arm Ltd isn't going to do anything, it's
old as far as they're concerned. It's up to those participating in the
kernel community to maintain and look after the code.

Thus, if there is a desire for something other than stop_machine() then
it is up to those who care about the issue to do something about it,
rather than expecting someone else to do something for them.

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

Re: [PATCH 4/5] ARM: Disable jump-label on PREEMPT_RT.

[Sebastian Andrzej Siewior]

On 2025-10-30 10:38:10 [+0000], Russell King (Oracle) wrote:
> On Thu, Oct 30, 2025 at 08:55:58AM +0100, Sebastian Andrzej Siewior wrote:
> > Arm64 and X86 replaced the stop_machine() logic with something else that
> > does not affect latency in that magnitude. If Arm could something
> > similar then fine but until then I don't see a way around it.
> 
> "If Arm could". For 32-bit, Arm Ltd isn't going to do anything, it's
> old as far as they're concerned. It's up to those participating in the
> kernel community to maintain and look after the code.
> 
> Thus, if there is a desire for something other than stop_machine() then
> it is up to those who care about the issue to do something about it,
> rather than expecting someone else to do something for them.

I fully understand. I've been told by several people to repost my ARM-RT
patches because they ("as in "the SoCs") appear to be of interest in
years to come. As individual vendor promise to deliver their SoCs for
10y+. It also claimed that new products appear with these SoCs. Now that
we have RT support in upstream kernel, ARM is one of the missing
architectures that was supported out of tree.

Having jump-labels disabled is what we had in the ARM-RT queue since
jump-labels were introduced. From around v4.0.8-rt6 it was considered
safe and enabled for x86, powerpc and arm64. From that point of view I
don't see a regression for the users.
And as you said, if there are ARM users who care and have an idea how to
optimize stop_machine() away they are welcome to post patches.

Sebastian

Re: [PATCH 4/5] ARM: Disable jump-label on PREEMPT_RT.

[Arnd Bergmann]

On Wed, Oct 29, 2025, at 16:59, Sebastian Andrzej Siewior wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
>
> jump-labels are used to efficiently switch between two possible code
> paths. To achieve this, stop_machine() is used to keep the CPU in a
> known state while the opcode is modified. The usage of stop_machine()
> here leads to large latency spikes which can be observed on PREEMPT_RT.
>
> Jump labels may change the target during runtime and are not restricted
> to debug or "configuration/ setup" part of a PREEMPT_RT system where
> high latencies could be defined as acceptable.
>
> Disable jump-label support on a PREEMPT_RT system.
>
> [bigeasy: Patch description.]
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
>  arch/arm/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 864a14a434b08..99c9b1c320af8 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -80,7 +80,7 @@ config ARM
>  	select HAS_IOPORT
>  	select HAVE_ARCH_AUDITSYSCALL if AEABI && !OABI_COMPAT
>  	select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
> -	select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
> +	select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU 
> && !PREEMPT_RT

I posted a slightly different version last year, which optimizes
the uniprocessor version and has a little more information
in the changelog:

https://lore.kernel.org/all/20241210160556.2341497-2-arnd@kernel.org/

     Arnd

Re: [PATCH 4/5] ARM: Disable jump-label on PREEMPT_RT.

[Sebastian Andrzej Siewior]

On 2025-10-30 16:24:16 [+0100], Arnd Bergmann wrote:
> On Wed, Oct 29, 2025, at 16:59, Sebastian Andrzej Siewior wrote:
> > From: Thomas Gleixner <tglx@linutronix.de>
> >
> > jump-labels are used to efficiently switch between two possible code
> > paths. To achieve this, stop_machine() is used to keep the CPU in a
> > known state while the opcode is modified. The usage of stop_machine()
> > here leads to large latency spikes which can be observed on PREEMPT_RT.
> >
> > Jump labels may change the target during runtime and are not restricted
> > to debug or "configuration/ setup" part of a PREEMPT_RT system where
> > high latencies could be defined as acceptable.
> >
> > Disable jump-label support on a PREEMPT_RT system.
> >
> > [bigeasy: Patch description.]
> >
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > ---
> >  arch/arm/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 864a14a434b08..99c9b1c320af8 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -80,7 +80,7 @@ config ARM
> >  	select HAS_IOPORT
> >  	select HAVE_ARCH_AUDITSYSCALL if AEABI && !OABI_COMPAT
> >  	select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
> > -	select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
> > +	select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU 
> > && !PREEMPT_RT
> 
> I posted a slightly different version last year, which optimizes
> the uniprocessor version and has a little more information
> in the changelog:
> 
> https://lore.kernel.org/all/20241210160556.2341497-2-arnd@kernel.org/

This actually slipped my mind but I was fine with it according the link.
So let me replace this, too.

>      Arnd

Sebastian

[PATCH 5/5] ARM: Allow to enable RT

[Sebastian Andrzej Siewior]

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

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 arch/arm/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 99c9b1c320af8..002db8da69ee5 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 if HAVE_POSIX_CPU_TIMERS_TASK_WORK
 	select ARCH_USE_BUILTIN_BSWAP
 	select ARCH_USE_CMPXCHG_LOCKREF
 	select ARCH_USE_MEMTEST
@@ -129,6 +130,7 @@ config ARM
 	select HAVE_PERF_EVENTS
 	select HAVE_PERF_REGS
 	select HAVE_PERF_USER_STACK_DUMP
+	select HAVE_POSIX_CPU_TIMERS_TASK_WORK if !KVM
 	select MMU_GATHER_RCU_TABLE_FREE if SMP && ARM_LPAE
 	select HAVE_REGS_AND_STACK_ACCESS_API
 	select HAVE_RSEQ
-- 
2.51.0

Re: [PATCH 5/5] ARM: Allow to enable RT

[Arnd Bergmann]

On Wed, Oct 29, 2025, at 16:59, Sebastian Andrzej Siewior wrote:
> All known issues have been adressed.
> Allow to select RT.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
>  arch/arm/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 99c9b1c320af8..002db8da69ee5 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 if HAVE_POSIX_CPU_TIMERS_TASK_WORK
>  	select ARCH_USE_BUILTIN_BSWAP
>  	select ARCH_USE_CMPXCHG_LOCKREF
>  	select ARCH_USE_MEMTEST
> @@ -129,6 +130,7 @@ config ARM
>  	select HAVE_PERF_EVENTS
>  	select HAVE_PERF_REGS
>  	select HAVE_PERF_USER_STACK_DUMP
> +	select HAVE_POSIX_CPU_TIMERS_TASK_WORK if !KVM
>  	select MMU_GATHER_RCU_TABLE_FREE if SMP && ARM_LPAE
>  	select HAVE_REGS_AND_STACK_ACCESS_API
>  	select HAVE_RSEQ

This can be simplified slightly since CONFIG_KVM is long gone on
ARM, so you can just select both HAVE_POSIX_CPU_TIMERS_TASK_WORK
and ARCH_SUPPORTS_RT unconditionally.

      Arnd

Re: [PATCH 5/5] ARM: Allow to enable RT

[Sebastian Andrzej Siewior]

On 2025-10-30 16:18:45 [+0100], Arnd Bergmann wrote:
> On Wed, Oct 29, 2025, at 16:59, Sebastian Andrzej Siewior wrote:
> > All known issues have been adressed.
> > Allow to select RT.
> >
> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > ---
> >  arch/arm/Kconfig | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 99c9b1c320af8..002db8da69ee5 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 if HAVE_POSIX_CPU_TIMERS_TASK_WORK
> >  	select ARCH_USE_BUILTIN_BSWAP
> >  	select ARCH_USE_CMPXCHG_LOCKREF
> >  	select ARCH_USE_MEMTEST
> > @@ -129,6 +130,7 @@ config ARM
> >  	select HAVE_PERF_EVENTS
> >  	select HAVE_PERF_REGS
> >  	select HAVE_PERF_USER_STACK_DUMP
> > +	select HAVE_POSIX_CPU_TIMERS_TASK_WORK if !KVM
> >  	select MMU_GATHER_RCU_TABLE_FREE if SMP && ARM_LPAE
> >  	select HAVE_REGS_AND_STACK_ACCESS_API
> >  	select HAVE_RSEQ
> 
> This can be simplified slightly since CONFIG_KVM is long gone on
> ARM, so you can just select both HAVE_POSIX_CPU_TIMERS_TASK_WORK
> and ARCH_SUPPORTS_RT unconditionally.

If ARM does not have KVM then I would not depend on
HAVE_POSIX_CPU_TIMERS_TASK_WORK since selecting it without providing it
is wrong. This can be implemented without the need of KVM or RT.

>       Arnd

Sebastian