linux-toradex.git/arch/arm64/kernel/irq.c, branch v7.0

arm64: use SOFTIRQ_ON_OWN_STACK for enabling softirq stack

2025-11-07T19:55:52+00:00

For those architectures with HAVE_SOFTIRQ_ON_OWN_STACK use
their dedicated softirq stack when !PREEMPT_RT. This condition
is ensured by SOFTIRQ_ON_OWN_STACK.

Let arm64 use SOFTIRQ_ON_OWN_STACK as well to select its
usage of the stack.

Signed-off-by: Ryo Takakura 
Reviewed-by: Sebastian Andrzej Siewior 
Acked-by: Will Deacon 
Signed-off-by: Catalin Marinas

arm64: remove CONFIG_VMAP_STACK conditionals from irq stack setup

2025-07-08T12:41:08+00:00

With VMAP_STACK always enabled on arm64, drop the CONFIG_VMAP_STACK
checks and legacy irq stack allocation from arch/arm64/kernel/irq.c. The
code now unconditionally uses the VMAP_STACK path for irq stack
initialization, simplifying the logic.

Signed-off-by: Breno Leitao 
Acked-by: Ard Biesheuvel 
Acked-by: Mark Rutland 
Link: https://lore.kernel.org/r/20250707-arm64_vmap-v1-4-8de98ca0f91c@debian.org
Signed-off-by: Will Deacon

arm64: irq: set the correct node for shadow call stack

2023-12-13T12:09:00+00:00

The init_irq_stacks() has been changed to use the correct node:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?id=75b5e0bf90bf

The init_irq_scs() has the same issue with init_irq_stacks():
	cpu_to_node() is not initialized yet, it does not work.

This patch uses early_cpu_to_node() to set the init_irq_scs()
with the correct node.

Signed-off-by: Huang Shijie 
Reviewed-by: Catalin Marinas 
Link: https://lore.kernel.org/r/20231213012046.12014-1-shijie@os.amperecomputing.com
Signed-off-by: Will Deacon

arm64: irq: set the correct node for VMAP stack

2023-12-05T14:26:50+00:00

In current code, init_irq_stacks() will call cpu_to_node().
The cpu_to_node() depends on percpu "numa_node" which is initialized in:
     arch_call_rest_init() --> rest_init() -- kernel_init()
	--> kernel_init_freeable() --> smp_prepare_cpus()

But init_irq_stacks() is called in init_IRQ() which is before
arch_call_rest_init().

So in init_irq_stacks(), the cpu_to_node() does not work, it
always return 0. In NUMA, it makes the node 1 cpu accesses the IRQ stack which
is in the node 0.

This patch fixes it by:
  1.) export the early_cpu_to_node(), and use it in the init_irq_stacks().
  2.) change init_irq_stacks() to __init function.

Reviewed-by: Catalin Marinas 
Signed-off-by: Huang Shijie 
Link: https://lore.kernel.org/r/20231124031513.81548-1-shijie@os.amperecomputing.com
Signed-off-by: Will Deacon

Merge branch 'for-next/stacks' into for-next/core

2022-12-06T11:26:40+00:00

* for-next/stacks:
  arm64: move on_thread_stack() to 
  arm64: remove current_top_of_stack()

arm64: move on_thread_stack() to

2022-11-18T14:36:47+00:00

Currently on_thread_stack() is defined in , depending
upon definitiong from  despite this header not being
included. This ends up being fragile, and any user of on_thread_stack()
must include both  and .

We organised things this way due to header dependencies back in commit:

  0b3e336601b82c6a ("arm64: Add support for STACKLEAK gcc plugin")

... but now that we no longer use current_top_of_stack(), and given that
stackleak includes  via , we no
longer need the definition to live in .

Move on_thread_stack() to , where all its dependencies
are guaranteed to be defined. This requires having arm64's irq.c
explicitly include , and I've taken the opportunity to
sort the includes, which were slightly out of order.

There should be no functional change as a result of this patch.

Signed-off-by: Mark Rutland 
Cc: Catalin Marinas 
Cc: Kees Cook 
Cc: Will Deacon 
Reviewed-by: Kees Cook 
Reviewed-by: Mark Brown 
Link: https://lore.kernel.org/r/20221117120902.3974163-3-mark.rutland@arm.com
Signed-off-by: Will Deacon

arm64: implement dynamic shadow call stack for Clang

2022-11-09T18:06:35+00:00

Implement dynamic shadow call stack support on Clang, by parsing the
unwind tables at init time to locate all occurrences of PACIASP/AUTIASP
instructions, and replacing them with the shadow call stack push and pop
instructions, respectively.

This is useful because the overhead of the shadow call stack is
difficult to justify on hardware that implements pointer authentication
(PAC), and given that the PAC instructions are executed as NOPs on
hardware that doesn't, we can just replace them without breaking
anything. As PACIASP/AUTIASP are guaranteed to be paired with respect to
manipulations of the return address, replacing them 1:1 with shadow call
stack pushes and pops is guaranteed to result in the desired behavior.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Sami Tolvanen 
Tested-by: Sami Tolvanen 
Link: https://lore.kernel.org/r/20221027155908.1940624-4-ardb@kernel.org
Signed-off-by: Will Deacon

arm64: run softirqs on the per-CPU IRQ stack

2022-09-09T18:01:38+00:00

Currently arm64 supports per-CPU IRQ stack, but softirqs
are still handled in the task context.

Since any call to local_bh_enable() at any level in the task's
call stack may trigger a softirq processing run, which could
potentially cause a task stack overflow if the combined stack
footprints exceed the stack's size, let's run these softirqs
on the IRQ stack as well.

Signed-off-by: Qi Zheng 
Reviewed-by: Arnd Bergmann 
Acked-by: Will Deacon 
Link: https://lore.kernel.org/r/20220815124739.15948-1-zhengqi.arch@bytedance.com
Signed-off-by: Catalin Marinas

arm64: irq: allow FIQs to be handled

2021-03-24T20:19:30+00:00

On contemporary platforms we don't use FIQ, and treat any stray FIQ as a
fatal event. However, some platforms have an interrupt controller wired
to FIQ, and need to handle FIQ as part of regular operation.

So that we can support both cases dynamically, this patch updates the
FIQ exception handling code to operate the same way as the IRQ handling
code, with its own handle_arch_fiq handler. Where a root FIQ handler is
not registered, an unexpected FIQ exception will trigger the default FIQ
handler, which will panic() as today. Where a root FIQ handler is
registered, handling of the FIQ is deferred to that handler.

As el0_fiq_invalid_compat is supplanted by el0_fiq, the former is
removed. For !CONFIG_COMPAT builds we never expect to take an exception
from AArch32 EL0, so we keep the common el0_fiq_invalid handler.

Signed-off-by: Mark Rutland 
Tested-by: Hector Martin 
Cc: James Morse 
Cc: Marc Zyngier 
Cc: Thomas Gleixner 
Cc: Will Deacon 
Acked-by: Will Deacon 
Link: https://lore.kernel.org/r/20210315115629.57191-7-mark.rutland@arm.com
Signed-off-by: Catalin Marinas

arm64: irq: rework root IRQ handler registration

2021-03-24T20:19:30+00:00

If we accidentally unmask IRQs before we've registered a root IRQ
handler, handle_arch_irq will be NULL, and the IRQ exception handler
will branch to a bogus address.

To make this easier to debug, this patch initialises handle_arch_irq to
a default handler which will panic(), making such problems easier to
debug. When we add support for FIQ handlers, we can follow the same
approach.

When we add support for a root FIQ handler, it's possible to have root
IRQ handler without an root FIQ handler, and in theory the inverse is
also possible. To permit this, and to keep the IRQ/FIQ registration
logic similar, this patch removes the panic in the absence of a root IRQ
controller. Instead, set_handle_irq() logs when a handler is registered,
which is sufficient for debug purposes.

Signed-off-by: Mark Rutland 
Tested-by: Hector Martin 
Cc: James Morse 
Cc: Marc Zyngier 
Cc: Thomas Gleixner 
Cc: Will Deacon 
Acked-by: Will Deacon 
Link: https://lore.kernel.org/r/20210315115629.57191-4-mark.rutland@arm.com
Signed-off-by: Catalin Marinas