Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 08 5月, 2022 2 次提交
    • A
      ARM: pxa: remove support for MTD_XIP · 5414bea9
      由 Arnd Bergmann 提交于 
      Using MTD-XIP does not work on multiplatform kernels because
it requires SoC specific register accesses to be done from
low-level flash handling functions in RAM while the rest of the
kernel sits in flash.

I found no evidence of anyone still actually using this feature,
so remove it from PXA to avoid spending a lot of time on
actually making it work.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      5414bea9
    • A
      ARM: pxa: move plat-pxa to drivers/soc/ · 64dbc4dd
      由 Arnd Bergmann 提交于 
      There are two drivers in arch/arm/plat-pxa: mfp and ssp. Both
of them should ideally not be needed at all, as there are
proper subsystems to replace them.

OTOH, they are self-contained and can simply be normal
SoC drivers, so move them over there to eliminate one more
of the plat-* directories.

Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> (mach-pxa)
Acked-by: Lubomir Rintel <lkundrak@v3.sk> (mach-mmp)
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      64dbc4dd
  3. 23 3月, 2022 2 次提交
  5. 18 3月, 2022 1 次提交
  7. 17 3月, 2022 1 次提交
    • A
      ARM: remove support for NOMMU ARMv4/v5 · 2f618d5e
      由 Arnd Bergmann 提交于 
      It is possible to build MMU-less kernels for Cortex-M base
microcrontrollers as well as a couple of older platforms that
have not been converted to CONFIG_ARCH_MULTIPLATFORM,
specifically ep93xx, footbridge, dove, sa1100 and s3c24xx.

It seems unlikely that anybody has tested those configurations
in recent years, as even building them is frequently broken.
A patch I submitted caused another build time regression
in this configuration. I sent a patch for that, but it seems
better to also remove the option entirely, leaving ARMv7-M
as the only supported Arm NOMMU target for simplicity.

A couple of platforms have dependencies on CONFIG_MMU, those
can all be removed now. Notably, mach-integrator tries to
support MMU-less CPU cores, but those have not actually been
selectable for a long time.

This addresses several build failures in randconfig builds that
have accumulated over the years.

Cc: Vladimir Murzin <vladimir.murzin@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      2f618d5e
  9. 12 3月, 2022 1 次提交
    • A
      ARM: fix building NOMMU ARMv4/v5 kernels · 234a0f20
      由 Arnd Bergmann 提交于 
      The removal of the old-style irq entry broke obscure NOMMU
configurations on machines that have an MMU:

ld.lld: error: undefined symbol: generic_handle_arch_irq
 referenced by kernel/entry-armv.o:(__irq_svc) in archive arch/arm/built-in.a

A follow-up patch to convert nvic to the generic_handle_arch_irq()
could have fixed this by removing the Kconfig conditional, but did
it differently.

Change the Kconfig logic so ARM machines now unconditionally
enable the feature.

I have also submitted a patch to remove support for the configurations
that broke, but fixing the regression first is a trivial and correct
change.
Reported-by: Nkernel test robot <lkp@intel.com>
Fixes: 54f481a2 ("ARM: remove old-style irq entry")
Fixes: 52d24087 ("irqchip: nvic: Use GENERIC_IRQ_MULTI_HANDLER")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      234a0f20
  11. 03 3月, 2022 1 次提交
    • C
      dma-mapping: remove CONFIG_DMA_REMAP · f5ff79fd
      由 Christoph Hellwig 提交于 
      CONFIG_DMA_REMAP is used to build a few helpers around the core
vmalloc code, and to use them in case there is a highmem page in
dma-direct, and to make dma coherent allocations be able to use
non-contiguous pages allocations for DMA allocations in the dma-iommu
layer.

Right now it needs to be explicitly selected by architectures, and
is only done so by architectures that require remapping to deal
with devices that are not DMA coherent.  Make it unconditional for
builds with CONFIG_MMU as it is very little extra code, but makes
it much more likely that large DMA allocations succeed on x86.

This fixes hot plugging a NVMe thunderbolt SSD for me, which tries
to allocate a 1MB buffer that is otherwise hard to obtain due to
memory fragmentation on a heavily used laptop.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
      f5ff79fd
  13. 01 3月, 2022 1 次提交
  15. 26 2月, 2022 1 次提交
    • K
      usercopy: Check valid lifetime via stack depth · 2792d84e
      由 Kees Cook 提交于 
      One of the things that CONFIG_HARDENED_USERCOPY sanity-checks is whether
an object that is about to be copied to/from userspace is overlapping
the stack at all. If it is, it performs a number of inexpensive
bounds checks. One of the finer-grained checks is whether an object
crosses stack frames within the stack region. Doing this on x86 with
CONFIG_FRAME_POINTER was cheap/easy. Doing it with ORC was deemed too
heavy, and was left out (a while ago), leaving the courser whole-stack
check.

The LKDTM tests USERCOPY_STACK_FRAME_TO and USERCOPY_STACK_FRAME_FROM
try to exercise these cross-frame cases to validate the defense is
working. They have been failing ever since ORC was added (which was
expected). While Muhammad was investigating various LKDTM failures[1],
he asked me for additional details on them, and I realized that when
exact stack frame boundary checking is not available (i.e. everything
except x86 with FRAME_POINTER), it could check if a stack object is at
least "current depth valid", in the sense that any object within the
stack region but not between start-of-stack and current_stack_pointer
should be considered unavailable (i.e. its lifetime is from a call no
longer present on the stack).

Introduce ARCH_HAS_CURRENT_STACK_POINTER to track which architectures
have actually implemented the common global register alias.

Additionally report usercopy bounds checking failures with an offset
from current_stack_pointer, which may assist with diagnosing failures.

The LKDTM USERCOPY_STACK_FRAME_TO and USERCOPY_STACK_FRAME_FROM tests
(once slightly adjusted in a separate patch) pass again with this fixed.

[1] https://github.com/kernelci/kernelci-project/issues/84

Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org
Reported-by: NMuhammad Usama Anjum <usama.anjum@collabora.com>
Signed-off-by: NKees Cook <keescook@chromium.org>
---
v1: https://lore.kernel.org/lkml/20220216201449.2087956-1-keescook@chromium.org
v2: https://lore.kernel.org/lkml/20220224060342.1855457-1-keescook@chromium.org
v3: https://lore.kernel.org/lkml/20220225173345.3358109-1-keescook@chromium.org
v4: - improve commit log (akpm)
      2792d84e
  17. 13 2月, 2022 3 次提交
  19. 10 2月, 2022 1 次提交
  21. 09 2月, 2022 1 次提交
    • A
      ARM: ftrace: enable the graph tracer with the EABI unwinder · 41918ec8
      由 Ard Biesheuvel 提交于 
      Enable the function graph tracer in combination with the EABI unwinder,
so that Thumb2 builds or Clang ARM builds can make use of it.

This involves using the unwinder to locate the return address of an
instrumented function on the stack, so that it can be overridden and
made to refer to the ftrace handling routines that need to be called at
function return.

Given that for these builds, it is not guaranteed that the value of the
link register is stored on the stack, fall back to the stack slot that
will be used by the ftrace exit code to restore LR in the instrumented
function's execution context.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Reviewed-by: NSteven Rostedt (Google) <rostedt@goodmis.org>
      41918ec8
  23. 28 1月, 2022 1 次提交
  25. 25 1月, 2022 2 次提交
  27. 05 1月, 2022 1 次提交
  29. 17 12月, 2021 1 次提交
  31. 06 12月, 2021 6 次提交
    • A
      ARM: v7m: enable support for IRQ stacks · cafc0eab
      由 Ard Biesheuvel 提交于 
      Enable support for IRQ stacks on !MMU, and add the code to the IRQ entry
path to switch to the IRQ stack if not running from it already.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Tested-by: NMarc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
      cafc0eab
    • A
      ARM: implement THREAD_INFO_IN_TASK for uniprocessor systems · 9c46929e
      由 Ard Biesheuvel 提交于 
      On UP systems, only a single task can be 'current' at the same time,
which means we can use a global variable to track it. This means we can
also enable THREAD_INFO_IN_TASK for those systems, as in that case,
thread_info is accessed via current rather than the other way around,
removing the need to store thread_info at the base of the task stack.
This, in turn, permits us to enable IRQ stacks and vmap'ed stacks on UP
systems as well.

To partially mitigate the performance overhead of this arrangement, use
a ADD/ADD/LDR sequence with the appropriate PC-relative group
relocations to load the value of current when needed. This means that
accessing current will still only require a single load as before,
avoiding the need for a literal to carry the address of the global
variable in each function. However, accessing thread_info will now
require this load as well.
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NNicolas Pitre <nico@fluxnic.net>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Tested-by: NMarc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
      9c46929e
    • A
      ARM: use TLS register for 'current' on !SMP as well · b87cf911
      由 Ard Biesheuvel 提交于 
      Enable the use of the TLS register to hold the 'current' pointer also on
non-SMP configurations that target v6k or later CPUs. This will permit
the use of THREAD_INFO_IN_TASK as well as IRQ stacks and vmap'ed stacks
for such configurations.
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NNicolas Pitre <nico@fluxnic.net>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Tested-by: NMarc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
      b87cf911
    • A
      ARM: remove old-style irq entry · 54f481a2
      由 Arnd Bergmann 提交于 
      The last user of arch_irq_handler_default is gone now, so the
entry-macro-multi.S file and all references to mach/entry-macro.S can
be removed, as well as the asm_do_IRQ() entrypoint into the interrupt
handling routines implemented in C.

Note: The ARMv7-M entry still uses its own top-level IRQ entry, calling
nvic_handle_irq() from assembly. This could be changed to go through
generic_handle_arch_irq() as well, but it's unclear to me if there are
any benefits.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
[ardb: keep irq_handler macro as it carries all the IRQ stack handling]
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Tested-by: NMarc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
      54f481a2
    • A
      ARM: iop32x: use GENERIC_IRQ_MULTI_HANDLER · 6f5d248d
      由 Arnd Bergmann 提交于 
      iop32x uses the entry-macro.S file for both the IRQ entry and for
hooking into the arch_ret_to_user code path. This is done because the
cp6 registers have to be enabled before accessing any of the interrupt
controller registers but have to be disabled when running in user space.

There is also a lazy-enable logic in cp6.c, but during a hardirq, we
know it has to be enabled.

Both the cp6-enable code and the code to read the IRQ status can be
lifted into the normal generic_handle_arch_irq() path, but the
cp6-disable code has to remain in the user return code. As nothing
other than iop32x uses this hook, just open-code it there with an
ifdef for the platform that can eventually be removed when iop32x
has reached the end of its life.

The cp6-enable path in the IRQ entry has an extra cp_wait barrier that
the trap version does not have, but it is harmless to do it in both
cases to simplify the logic here at the cost of a few extra cycles
for the trap.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Tested-by: NMarc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
      6f5d248d
    • A
      ARM: footbridge: use GENERIC_IRQ_MULTI_HANDLER · 90890f17
      由 Arnd Bergmann 提交于 
      Footbridge still uses the classic IRQ entry path in assembler,
but this is easily converted into an equivalent C version.

In this case, the correlation between IRQ numbers and bits in
the status register is non-obvious, and the priorities are
handled by manually checking each bit in a static order,
re-reading the status register after each handled event.

I moved the code into the new file and edited the syntax without
changing this sequence to keep the behavior as close as possible
to what it traditionally did.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Tested-by: NMarc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
      90890f17
  33. 04 12月, 2021 1 次提交
    • A
      ARM: riscpc: use GENERIC_IRQ_MULTI_HANDLER · c1fe8d05
      由 Arnd Bergmann 提交于 
      This is one of the last platforms using the old entry path.
While this code path is spread over a few files, it is fairly
straightforward to convert it into an equivalent C version,
leaving the existing algorithm and all the priority handling
the same.

Unlike most irqchip drivers, this means reading the status
register(s) in a loop and always handling the highest-priority
irq first.

The IOMD_IRQREQC and IOMD_IRQREQD registers are not actaully
used here, but I left the code in place for the time being,
to keep the conversion as direct as possible. It could be
removed in a cleanup on top.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
[ardb: drop obsolete IOMD_IRQREQC/IOMD_IRQREQD handling]
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Tested-by: NMarc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
      c1fe8d05
  35. 03 12月, 2021 4 次提交
    • A
      ARM: implement support for vmap'ed stacks · a1c510d0
      由 Ard Biesheuvel 提交于 
      Wire up the generic support for managing task stack allocations via vmalloc,
and implement the entry code that detects whether we faulted because of a
stack overrun (or future stack overrun caused by pushing the pt_regs array)

While this adds a fair amount of tricky entry asm code, it should be
noted that it only adds a TST + branch to the svc_entry path. The code
implementing the non-trivial handling of the overflow stack is emitted
out-of-line into the .text section.

Since on ARM, we rely on do_translation_fault() to keep PMD level page
table entries that cover the vmalloc region up to date, we need to
ensure that we don't hit such a stale PMD entry when accessing the
stack. So we do a dummy read from the new stack while still running from
the old one on the context switch path, and bump the vmalloc_seq counter
when PMD level entries in the vmalloc range are modified, so that the MM
switch fetches the latest version of the entries.

Note that we need to increase the per-mode stack by 1 word, to gain some
space to stash a GPR until we know it is safe to touch the stack.
However, due to the cacheline alignment of the struct, this does not
actually increase the memory footprint of the struct stack array at all.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Tested-by: NKeith Packard <keithpac@amazon.com>
Tested-by: NMarc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
      a1c510d0
    • A
      ARM: run softirqs on the per-CPU IRQ stack · 9974f857
      由 Ard Biesheuvel 提交于 
      Now that we have enabled IRQ stacks, any softIRQs that are handled over
the back of a hard IRQ will run from the IRQ stack as well. However, any
synchronous softirq processing that happens when re-enabling softIRQs
from task context will still execute on that task's stack.

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 synchronous invocations of do_softirq() on
the IRQ stack as well.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NKeith Packard <keithpac@amazon.com>
Tested-by: NMarc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
      9974f857
    • A
      ARM: implement IRQ stacks · d4664b6c
      由 Ard Biesheuvel 提交于 
      Now that we no longer rely on the stack pointer to access the current
task struct or thread info, we can implement support for IRQ stacks
cleanly as well.

Define a per-CPU IRQ stack and switch to this stack when taking an IRQ,
provided that we were not already using that stack in the interrupted
context. This is never the case for IRQs taken from user space, but ones
taken while running in the kernel could fire while one taken from user
space has not completed yet.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NKeith Packard <keithpac@amazon.com>
Acked-by: NNick Desaulniers <ndesaulniers@google.com>
Tested-by: NMarc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
      d4664b6c
    • A
      ARM: stackprotector: prefer compiler for TLS based per-task protector · f05eb1d2
      由 Ard Biesheuvel 提交于 
      Currently, we implement the per-task stack protector for ARM using a GCC
plugin, due to lack of native compiler support. However, work is
underway to get this implemented in the compiler, which means we will be
able to deprecate the GCC plugin at some point.

In the meantime, we will need to support both, where the native compiler
implementation is obviously preferred. So let's wire this up in Kconfig
and the Makefile.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Tested-by: NMarc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
      f05eb1d2
  37. 25 11月, 2021 1 次提交
  39. 22 11月, 2021 1 次提交
  41. 21 11月, 2021 1 次提交
  43. 26 10月, 2021 1 次提交
    • M
      irq: remove handle_domain_{irq,nmi}() · 0953fb26
      由 Mark Rutland 提交于 
      Now that entry code handles IRQ entry (including setting the IRQ regs)
before calling irqchip code, irqchip code can safely call
generic_handle_domain_irq(), and there's no functional reason for it to
call handle_domain_irq().

Let's cement this split of responsibility and remove handle_domain_irq()
entirely, updating irqchip drivers to call generic_handle_domain_irq().

For consistency, handle_domain_nmi() is similarly removed and replaced
with a generic_handle_domain_nmi() function which also does not perform
any entry logic.

Previously handle_domain_{irq,nmi}() had a WARN_ON() which would fire
when they were called in an inappropriate context. So that we can
identify similar issues going forward, similar WARN_ON_ONCE() logic is
added to the generic_handle_*() functions, and comments are updated for
clarity and consistency.
Signed-off-by: NMark Rutland <mark.rutland@arm.com>
Reviewed-by: NMarc Zyngier <maz@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
      0953fb26
  45. 25 10月, 2021 5 次提交
    • A
      ARM: 9146/1: RiscPC needs older gcc version · 2abd6e34
      由 Arnd Bergmann 提交于 
      Attempting to build mach-rpc with gcc-9 or higher, or with any version
of clang results in a build failure, like:

arm-linux-gnueabi-gcc-11.1.0: error: unrecognized -march target: armv3m
arm-linux-gnueabi-gcc-11.1.0: note: valid arguments are: armv4 armv4t armv5t armv5te armv5tej armv6 armv6j armv6k armv6z armv6kz armv6zk armv6t2 armv6-m armv6s-m armv7 armv7-a armv7ve armv7-r armv7-m armv7e-m armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a armv8.5-a armv8.6-a armv8-m.base armv8-m.main armv8-r armv8.1-m.main iwmmxt iwmmxt2; did you mean 'armv4'?

Building with gcc-5 also fails in at least one of these ways:

/tmp/cczZoCcv.s:68: Error: selected processor does not support `bx lr' in ARM mode
drivers/tty/vt/vt_ioctl.c:958:1: internal compiler error: Segmentation fault

Handle this in Kconfig so we don't run into this with randconfig
builds, allowing only gcc-6 through gcc-8.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      2abd6e34
    • A
      ARM: 9144/1: forbid ftrace with clang and thumb2_kernel · ecb108e3
      由 Arnd Bergmann 提交于 
      clang fails to build kernels with THUMB2 and FUNCTION_TRACER
enabled when there is any inline asm statement containing
the frame pointer register r7:

arch/arm/mach-exynos/mcpm-exynos.c:154:2: error: inline asm clobber list contains reserved registers: R7 [-Werror,-Winline-asm]
arch/arm/probes/kprobes/actions-thumb.c:449:3: error: inline asm clobber list contains reserved registers: R7 [-Werror,-Winline-asm]

Apparently gcc should also have warned about this, and the
configuration is actually invalid, though there is some
disagreement on the bug trackers about this.

Link: https://bugs.llvm.org/show_bug.cgi?id=45826
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94986Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      ecb108e3
    • A
      ARM: 9143/1: add CONFIG_PHYS_OFFSET default values · c6e77bb6
      由 Arnd Bergmann 提交于 
      For platforms that are not yet converted to ARCH_MULTIPLATFORM,
we can disable CONFIG_ARM_PATCH_PHYS_VIRT, which in turn requires
setting a correct address here.

As we actualy know what all the values are supposed to be based
on the old mach/memory.h header file contents (from git history),
we can just add them here.

This also solves a problem in Kconfig where 'make randconfig'
fails to continue if no number is selected for a 'hex' option.
Users can still override the number at configuration time, e.g.
when the memory visible to the kernel starts at a nonstandard
address on some machine, but it should no longer be required
now.

I originally posted this back in 2016, but the problem still
persists. The patch has gotten much simpler though, as almost
all platforms rely on ARM_PATCH_PHYS_VIRT now.

Link: https://lore.kernel.org/linux-arm-kernel/1455804123-2526139-5-git-send-email-arnd@arndb.de/Acked-by: NNicolas Pitre <nico@fluxnic.net>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      c6e77bb6
    • M
      irq: arm: perform irqentry in entry code · a7b0872e
      由 Mark Rutland 提交于 
      In preparation for removing HANDLE_DOMAIN_IRQ_IRQENTRY, have arch/arm
perform all the irqentry accounting in its entry code.

For configurations with CONFIG_GENERIC_IRQ_MULTI_HANDLER, we can use
generic_handle_arch_irq(). Other than asm_do_IRQ(), all C calls to
handle_IRQ() are from irqchip handlers which will be called from
generic_handle_arch_irq(), so to avoid double accounting IRQ entry, the
entry logic is moved from handle_IRQ() into asm_do_IRQ().

For ARMv7M the entry assembly is tightly coupled with the NVIC irqchip, and
while the entry code should logically live under arch/arm/, moving the
entry logic there makes things more convoluted. So for now, place the
entry logic in the NVIC irqchip, but separated into a separate
function to make the split of responsibility clear.

For all other configurations without CONFIG_GENERIC_IRQ_MULTI_HANDLER,
IRQ entry is already handled in arch code, and requires no changes.

There should be no functional change as a result of this patch.
Signed-off-by: NMark Rutland <mark.rutland@arm.com>
Reviewed-by: NMarc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
Cc: Russell King <linux@armlinux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
      a7b0872e
    • M
      irq: add a (temporary) CONFIG_HANDLE_DOMAIN_IRQ_IRQENTRY · 2fe35f8e
      由 Mark Rutland 提交于 
      Going forward we want architecture/entry code to perform all the
necessary work to enter/exit IRQ context, with irqchip code merely
handling the mapping of the interrupt to any handler(s). Among other
reasons, this is necessary to consistently fix some longstanding issues
with the ordering of lockdep/RCU/tracing instrumentation which many
architectures get wrong today in their entry code.

Importantly, rcu_irq_{enter,exit}() must be called precisely once per
IRQ exception, so that rcu_is_cpu_rrupt_from_idle() can correctly
identify when an interrupt was taken from an idle context which must be
explicitly preempted. Currently handle_domain_irq() calls
rcu_irq_{enter,exit}() via irq_{enter,exit}(), but entry code needs to
be able to call rcu_irq_{enter,exit}() earlier for correct ordering
across lockdep/RCU/tracing updates for sequences such as:

  lockdep_hardirqs_off(CALLER_ADDR0);
  rcu_irq_enter();
  trace_hardirqs_off_finish();

To permit each architecture to be converted to the new style in turn,
this patch adds a new CONFIG_HANDLE_DOMAIN_IRQ_IRQENTRY selected by all
current users of HANDLE_DOMAIN_IRQ, which gates the existing behaviour.
When CONFIG_HANDLE_DOMAIN_IRQ_IRQENTRY is not selected,
handle_domain_irq() requires entry code to perform the
irq_{enter,exit}() work, with an explicit check for this matching the
style of handle_domain_nmi().

Subsequent patches will:

1) Add the necessary IRQ entry accounting to each architecture in turn,
   dropping CONFIG_HANDLE_DOMAIN_IRQ_IRQENTRY from that architecture's
   Kconfig.

2) Remove CONFIG_HANDLE_DOMAIN_IRQ_IRQENTRY once it is no longer
   selected.

3) Convert irqchip drivers to consistently use
   generic_handle_domain_irq() rather than handle_domain_irq().

4) Remove handle_domain_irq() and CONFIG_HANDLE_DOMAIN_IRQ.

... which should leave us with a clear split of responsiblity across the
entry and irqchip code, making it possible to perform additional
cleanups and fixes for the aforementioned longstanding issues with entry
code.

There should be no functional change as a result of this patch.
Signed-off-by: NMark Rutland <mark.rutland@arm.com>
Reviewed-by: NMarc Zyngier <maz@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
      2fe35f8e