mbox series

[v5,00/32] ARM vmap'ed and IRQ stacks roundup

Message ID 20220124174744.1054712-1-ardb@kernel.org (mailing list archive)
Headers show
Series ARM vmap'ed and IRQ stacks roundup | expand

Message

Ard Biesheuvel Jan. 24, 2022, 5:47 p.m. UTC
This v5 series is a combined followup to

- IRQ stacks support for v7 SMP systems [0],
- vmap'ed stacks support for v7 SMP systems[1],
- extending support for both IRQ stacks and vmap'ed stacks for all
  remaining configurations, including v6/v7 SMP multiplatform kernels
  and uniprocessor configurations including v7-M [2]

[0] https://lore.kernel.org/linux-arm-kernel/20211115084732.3704393-1-ardb@kernel.org/
[1] https://lore.kernel.org/linux-arm-kernel/20211122092816.2865873-1-ardb@kernel.org/
[2] https://lore.kernel.org/linux-arm-kernel/20211206164659.1495084-1-ardb@kernel.org/

This work was queued up in the ARM tree for a while, but due to problems
with the vmap'ed stacks code, which was difficult to revert in
isolation, the whole stack was dropped again.

In order to prevent similar problems from occurring this time around,
the series was reorganized so that the vmap'ed stacks changes appear at
the very end, which also results in a more natural progression of the
changes.

Changes since v4:
- incorporate fixups to avoid build failures on Clang related to
  literals in subsections,
- switch from the ID map to swapper_pg_dir as early as possible when
  onlining a CPU on !LPAE, to ensure that the stack is mapped,
- use SMP_ON_UP patching to elide HWCAP_TLS tests on SMP+v6,
- clean up __switch_to() for Thumb2 a bit more,
- add patch to make the vmalloc_seq counter SMP safe,
- use enter_lazy_tlb() hook on !LPAE to ensure that the active_mm used
  by a kernel thread has a mapping for its vmap'ed stack,

Code can be found under the arm-vmap-stacks-v5 tag at
git://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git

Cc: Russell King <linux@armlinux.org.uk>
Cc: Nicolas Pitre <nico@fluxnic.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Kees Cook <keescook@chromium.org>
Cc: Keith Packard <keithpac@amazon.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Vladimir Murzin <vladimir.murzin@arm.com>
Cc: Jesse Taube <mr.bossman075@gmail.com>

Ard Biesheuvel (26):
  ARM: riscpc: drop support for IOMD_IRQREQC/IOMD_IRQREQD IRQ groups
  ARM: decompressor: disable stack protector
  ARM: stackprotector: prefer compiler for TLS based per-task protector
  ARM: entry: preserve thread_info pointer in switch_to
  ARM: module: implement support for PC-relative group relocations
  ARM: assembler: add optimized ldr/str macros to load variables from
    memory
  ARM: percpu: add SMP_ON_UP support
  ARM: use TLS register for 'current' on !SMP as well
  ARM: smp: defer TPIDRURO update for SMP v6 configurations too
  ARM: implement THREAD_INFO_IN_TASK for uniprocessor systems
  ARM: assembler: introduce bl_r macro
  ARM: unwind: support unwinding across multiple stacks
  ARM: export dump_mem() to other objects
  ARM: unwind: dump exception stack from calling frame
  ARM: backtrace-clang: avoid crash on bogus frame pointer
  ARM: implement IRQ stacks
  ARM: call_with_stack: add unwind support
  ARM: run softirqs on the per-CPU IRQ stack
  ARM: memcpy: use frame pointer as unwind anchor
  ARM: memmove: use frame pointer as unwind anchor
  ARM: memset: clean up unwind annotations
  ARM: unwind: disregard unwind info before stack frame is set up
  ARM: entry: rework stack realignment code in svc_entry
  ARM: switch_to: clean up Thumb2 code path
  ARM: mm: prepare vmalloc_seq handling for use under SMP
  ARM: implement support for vmap'ed stacks

Arnd Bergmann (5):
  ARM: riscpc: use GENERIC_IRQ_MULTI_HANDLER
  ARM: footbridge: use GENERIC_IRQ_MULTI_HANDLER
  ARM: iop32x: offset IRQ numbers by 1
  ARM: iop32x: use GENERIC_IRQ_MULTI_HANDLER
  ARM: remove old-style irq entry

Vladimir Murzin (1):
  irqchip: nvic: Use GENERIC_IRQ_MULTI_HANDLER

 arch/arm/Kconfig                                    |  39 ++--
 arch/arm/Makefile                                   |   9 +
 arch/arm/boot/compressed/Makefile                   |   6 +-
 arch/arm/boot/compressed/misc.c                     |   7 -
 arch/arm/include/asm/assembler.h                    | 209 ++++++++++++++++----
 arch/arm/include/asm/current.h                      |  47 +++--
 arch/arm/include/asm/elf.h                          |   3 +
 arch/arm/include/asm/entry-macro-multi.S            |  40 ----
 arch/arm/include/asm/hardware/entry-macro-iomd.S    | 131 ------------
 arch/arm/include/asm/insn.h                         |  17 ++
 arch/arm/include/asm/irq.h                          |   1 -
 arch/arm/include/asm/mach/arch.h                    |   2 -
 arch/arm/include/asm/mmu.h                          |   2 +-
 arch/arm/include/asm/mmu_context.h                  |  22 ++-
 arch/arm/include/asm/page.h                         |   3 +
 arch/arm/include/asm/percpu.h                       |  36 +++-
 arch/arm/include/asm/smp.h                          |   5 -
 arch/arm/include/asm/stacktrace.h                   |  12 ++
 arch/arm/include/asm/switch_to.h                    |   3 +-
 arch/arm/include/asm/thread_info.h                  |  35 +---
 arch/arm/include/asm/tls.h                          |  30 ++-
 arch/arm/include/asm/v7m.h                          |   3 +-
 arch/arm/kernel/asm-offsets.c                       |   3 -
 arch/arm/kernel/entry-armv.S                        | 208 +++++++++++++++----
 arch/arm/kernel/entry-common.S                      |  16 +-
 arch/arm/kernel/entry-header.S                      |  47 ++++-
 arch/arm/kernel/entry-v7m.S                         |  39 ++--
 arch/arm/kernel/head-common.S                       |   4 +-
 arch/arm/kernel/head.S                              |   7 +
 arch/arm/kernel/irq.c                               |  55 ++++--
 arch/arm/kernel/module.c                            |  90 +++++++++
 arch/arm/kernel/process.c                           |   7 +-
 arch/arm/kernel/setup.c                             |   8 +-
 arch/arm/kernel/sleep.S                             |  13 ++
 arch/arm/kernel/smp.c                               |  11 +-
 arch/arm/kernel/traps.c                             |  92 ++++++++-
 arch/arm/kernel/unwind.c                            |  50 +++--
 arch/arm/kernel/vmlinux.lds.S                       |   4 +-
 arch/arm/lib/backtrace-clang.S                      |  13 +-
 arch/arm/lib/backtrace.S                            |   7 +
 arch/arm/lib/call_with_stack.S                      |  33 +++-
 arch/arm/lib/copy_from_user.S                       |  13 +-
 arch/arm/lib/copy_template.S                        |  67 +++----
 arch/arm/lib/copy_to_user.S                         |  13 +-
 arch/arm/lib/memcpy.S                               |  13 +-
 arch/arm/lib/memmove.S                              |  60 ++----
 arch/arm/lib/memset.S                               |   7 +-
 arch/arm/mach-footbridge/common.c                   |  87 ++++++++
 arch/arm/mach-footbridge/include/mach/entry-macro.S | 107 ----------
 arch/arm/mach-iop32x/cp6.c                          |  10 +-
 arch/arm/mach-iop32x/include/mach/entry-macro.S     |  31 ---
 arch/arm/mach-iop32x/include/mach/irqs.h            |   2 +-
 arch/arm/mach-iop32x/iop3xx.h                       |   1 +
 arch/arm/mach-iop32x/irq.c                          |  29 ++-
 arch/arm/mach-iop32x/irqs.h                         |  60 +++---
 arch/arm/mach-rpc/fiq.S                             |   5 +-
 arch/arm/mach-rpc/include/mach/entry-macro.S        |  13 --
 arch/arm/mach-rpc/irq.c                             |  95 +++++++++
 arch/arm/mm/Kconfig                                 |   1 +
 arch/arm/mm/context.c                               |   3 +-
 arch/arm/mm/ioremap.c                               |  18 +-
 drivers/irqchip/Kconfig                             |   1 +
 drivers/irqchip/irq-nvic.c                          |  22 +--
 63 files changed, 1270 insertions(+), 757 deletions(-)
 delete mode 100644 arch/arm/include/asm/entry-macro-multi.S
 delete mode 100644 arch/arm/include/asm/hardware/entry-macro-iomd.S
 delete mode 100644 arch/arm/mach-footbridge/include/mach/entry-macro.S
 delete mode 100644 arch/arm/mach-iop32x/include/mach/entry-macro.S
 delete mode 100644 arch/arm/mach-rpc/include/mach/entry-macro.S

Comments

Russell King (Oracle) Jan. 24, 2022, 5:56 p.m. UTC | #1
On Mon, Jan 24, 2022 at 06:47:12PM +0100, Ard Biesheuvel wrote:
> This v5 series is a combined followup to
> 
> - IRQ stacks support for v7 SMP systems [0],
> - vmap'ed stacks support for v7 SMP systems[1],
> - extending support for both IRQ stacks and vmap'ed stacks for all
>   remaining configurations, including v6/v7 SMP multiplatform kernels
>   and uniprocessor configurations including v7-M [2]
> 
> [0] https://lore.kernel.org/linux-arm-kernel/20211115084732.3704393-1-ardb@kernel.org/
> [1] https://lore.kernel.org/linux-arm-kernel/20211122092816.2865873-1-ardb@kernel.org/
> [2] https://lore.kernel.org/linux-arm-kernel/20211206164659.1495084-1-ardb@kernel.org/
> 
> This work was queued up in the ARM tree for a while, but due to problems
> with the vmap'ed stacks code, which was difficult to revert in
> isolation, the whole stack was dropped again.
> 
> In order to prevent similar problems from occurring this time around,
> the series was reorganized so that the vmap'ed stacks changes appear at
> the very end, which also results in a more natural progression of the
> changes.
> 
> Changes since v4:
> - incorporate fixups to avoid build failures on Clang related to
>   literals in subsections,
> - switch from the ID map to swapper_pg_dir as early as possible when
>   onlining a CPU on !LPAE, to ensure that the stack is mapped,
> - use SMP_ON_UP patching to elide HWCAP_TLS tests on SMP+v6,
> - clean up __switch_to() for Thumb2 a bit more,
> - add patch to make the vmalloc_seq counter SMP safe,
> - use enter_lazy_tlb() hook on !LPAE to ensure that the active_mm used
>   by a kernel thread has a mapping for its vmap'ed stack,

Hi Ard,

I still have the original code in devel-stable, and being a guaranteed
stable branch, it's not something I'll be dropping... Please can I have
fixes on top of what is already there please?

Thanks.
Ard Biesheuvel Jan. 24, 2022, 5:57 p.m. UTC | #2
On Mon, 24 Jan 2022 at 18:57, Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
>
> On Mon, Jan 24, 2022 at 06:47:12PM +0100, Ard Biesheuvel wrote:
> > This v5 series is a combined followup to
> >
> > - IRQ stacks support for v7 SMP systems [0],
> > - vmap'ed stacks support for v7 SMP systems[1],
> > - extending support for both IRQ stacks and vmap'ed stacks for all
> >   remaining configurations, including v6/v7 SMP multiplatform kernels
> >   and uniprocessor configurations including v7-M [2]
> >
> > [0] https://lore.kernel.org/linux-arm-kernel/20211115084732.3704393-1-ardb@kernel.org/
> > [1] https://lore.kernel.org/linux-arm-kernel/20211122092816.2865873-1-ardb@kernel.org/
> > [2] https://lore.kernel.org/linux-arm-kernel/20211206164659.1495084-1-ardb@kernel.org/
> >
> > This work was queued up in the ARM tree for a while, but due to problems
> > with the vmap'ed stacks code, which was difficult to revert in
> > isolation, the whole stack was dropped again.
> >
> > In order to prevent similar problems from occurring this time around,
> > the series was reorganized so that the vmap'ed stacks changes appear at
> > the very end, which also results in a more natural progression of the
> > changes.
> >
> > Changes since v4:
> > - incorporate fixups to avoid build failures on Clang related to
> >   literals in subsections,
> > - switch from the ID map to swapper_pg_dir as early as possible when
> >   onlining a CPU on !LPAE, to ensure that the stack is mapped,
> > - use SMP_ON_UP patching to elide HWCAP_TLS tests on SMP+v6,
> > - clean up __switch_to() for Thumb2 a bit more,
> > - add patch to make the vmalloc_seq counter SMP safe,
> > - use enter_lazy_tlb() hook on !LPAE to ensure that the active_mm used
> >   by a kernel thread has a mapping for its vmap'ed stack,
>
> Hi Ard,
>
> I still have the original code in devel-stable, and being a guaranteed
> stable branch, it's not something I'll be dropping... Please can I have
> fixes on top of what is already there please?
>

Sure.