1. 04 Feb, 2020 5 commits
  2. 27 Jan, 2020 6 commits
  3. 25 Jan, 2020 8 commits
    • Vladimir Murzin's avatar
      ARM: 8954/1: NOMMU: remove stubs for swapops · 03a575a6
      Vladimir Murzin authored
      Stubs for swapops are not required after 9b98fa22
       (mm: stub out
      all of swapops.h for !CONFIG_MMU)
      Signed-off-by: Vladimir Murzin's avatarVladimir Murzin <vladimir.murzin@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
    • Vincenzo Frascino's avatar
      ARM: 8952/1: Disable kmemleak on XIP kernels · bc420c6c
      Vincenzo Frascino authored
      Kmemleak relies on specific symbols to register the read only data
      during init (e.g. __start_ro_after_init).
      Trying to build an XIP kernel on arm results in the linking error
      reported below because when this option is selected read only data
      after init are not allowed since .data is read only (.rodata).
        arm-linux-gnueabihf-ld: mm/kmemleak.o: in function `kmemleak_init':
        kmemleak.c:(.init.text+0x148): undefined reference to `__end_ro_after_init'
        arm-linux-gnueabihf-ld: kmemleak.c:(.init.text+0x14c):
           undefined reference to `__end_ro_after_init'
        arm-linux-gnueabihf-ld: kmemleak.c:(.init.text+0x150):
           undefined reference to `__start_ro_after_init'
        arm-linux-gnueabihf-ld: kmemleak.c:(.init.text+0x156):
           undefined reference to `__start_ro_after_init'
        arm-linux-gnueabihf-ld: kmemleak.c:(.init.text+0x162):
           undefined reference to `__start_ro_after_init'
        arm-linux-gnueabihf-ld: kmemleak.c:(.init.text+0x16a):
           undefined reference to `__start_ro_after_init'
        linux/Makefile:1078: recipe for target 'vmlinux' failed
      Fix the issue enabling kmemleak only on non XIP kernels.
      Signed-off-by: Vincenzo Frascino's avatarVincenzo Frascino <vincenzo.frascino@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
    • Vincenzo Frascino's avatar
      ARM: 8951/1: Fix Kexec compilation issue. · 76950f71
      Vincenzo Frascino authored
      To perform the reserve_crashkernel() operation kexec uses SECTION_SIZE to
      find a memblock in a range.
      SECTION_SIZE is not defined for nommu systems. Trying to compile kexec in
      these conditions results in a build error:
        linux/arch/arm/kernel/setup.c: In function ‘reserve_crashkernel’:
        linux/arch/arm/kernel/setup.c:1016:25: error: ‘SECTION_SIZE’ undeclared
           (first use in this function); did you mean ‘SECTIONS_WIDTH’?
                   crash_size, SECTION_SIZE);
        linux/arch/arm/kernel/setup.c:1016:25: note: each undeclared identifier
           is reported only once for each function it appears in
        linux/scripts/Makefile.build:265: recipe for target 'arch/arm/kernel/setup.o'
      Make KEXEC depend on MMU to fix the compilation issue.
      Signed-off-by: Vincenzo Frascino's avatarVincenzo Frascino <vincenzo.frascino@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
    • Olof Johansson's avatar
      ARM: 8949/1: mm: mark free_memmap as __init · 31f3010e
      Olof Johansson authored
      As of commit ac7c3e4f ("compiler: enable CONFIG_OPTIMIZE_INLINING
      forcibly"), free_memmap() might not always be inlined, and thus is
      triggering a section warning:
      WARNING: vmlinux.o(.text.unlikely+0x904): Section mismatch in reference from the function free_memmap() to the function .meminit.text:memblock_free()
      Mark it as __init, since the faller (free_unused_memmap) already is.
      Fixes: ac7c3e4f
       ("compiler: enable CONFIG_OPTIMIZE_INLINING forcibly")
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
    • Vincent Whitchurch's avatar
      ARM: 8948/1: Prevent OOB access in stacktrace · 40ff1ddb
      Vincent Whitchurch authored
      The stacktrace code can read beyond the stack size, when it attempts to
      read pt_regs from exception frames.
      This can happen on normal, non-corrupt stacks.  Since the unwind
      information in the extable is not correct for function prologues, the
      unwinding code can return data from the stack which is not actually the
      caller function address, and if in_entry_text() happens to succeed on
      this value, we can end up reading data from outside the task's stack
      when attempting to read pt_regs, since there is no bounds check.
       [<8010e729>] (unwind_backtrace) from [<8010a9c9>] (show_stack+0x11/0x14)
       [<8010a9c9>] (show_stack) from [<8057d8d7>] (dump_stack+0x87/0xac)
       [<8057d8d7>] (dump_stack) from [<8012271d>] (tasklet_action_common.constprop.4+0xa5/0xa8)
       [<8012271d>] (tasklet_action_common.constprop.4) from [<80102333>] (__do_softirq+0x11b/0x31c)
       [<80102333>] (__do_softirq) from [<80122485>] (irq_exit+0xad/0xd8)
       [<80122485>] (irq_exit) from [<8015f3d7>] (__handle_domain_irq+0x47/0x84)
       [<8015f3d7>] (__handle_domain_irq) from [<8036a523>] (gic_handle_irq+0x43/0x78)
       [<8036a523>] (gic_handle_irq) from [<80101a49>] (__irq_svc+0x69/0xb4)
       Exception stack(0xeb491f58 to 0xeb491fa0)
       1f40:                                                       7eb14794 00000000
       1f60: ffffffff 008dd32c 008dd324 ffffffff 008dd314 0000002a 801011e4 eb490000
       1f80: 0000002a 7eb1478c 50c5387d eb491fa8 80101001 8023d09c 40080033 ffffffff
       [<80101a49>] (__irq_svc) from [<8023d09c>] (do_pipe2+0x0/0xac)
       [<8023d09c>] (do_pipe2) from [<ffffffff>] (0xffffffff)
       Exception stack(0xeb491fc8 to 0xeb492010)
       1fc0:                   008dd314 0000002a 00511ad8 008de4c8 7eb14790 7eb1478c
       1fe0: 00511e34 7eb14774 004c8557 76f44098 60080030 7eb14794 00000000 00000000
       2000: 00000001 00000000 ea846c00 ea847cc0
      In this example, the stack limit is 0xeb492000, but 16 bytes outside the
      stack have been read.
      Fix it by adding bounds checks.
      Signed-off-by: default avatarVincent Whitchurch <vincent.whitchurch@axis.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
    • Masahiro Yamada's avatar
      ARM: 8945/1: decompressor: use CONFIG option instead of cc-option · 9db78852
      Masahiro Yamada authored
      The Kconfig stage (arch/Kconfig) has already evaluated whether the
      compiler supports -fno-stack-protector.
      You can use CONFIG_CC_HAS_STACKPROTECTOR_NONE instead of invoking
      the compiler to check the flag here.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
    • Ard Biesheuvel's avatar
      ARM: 8942/1: Revert "8857/1: efi: enable CP15 DMB instructions before cleaning the cache" · cf17a1e3
      Ard Biesheuvel authored
      This reverts commit e17b1af9
      , which is
      no longer necessary now that the v7 specific routines take care not to
      issue CP15 barrier instructions before they are enabled in SCTLR.
      Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
    • Ard Biesheuvel's avatar
      ARM: 8941/1: decompressor: enable CP15 barrier instructions in v7 cache setup code · 8239fc77
      Ard Biesheuvel authored
      Commit e17b1af9
        "ARM: 8857/1: efi: enable CP15 DMB instructions before cleaning the cache"
      added some explicit handling of the CP15BEN bit in the SCTLR system
      register, to ensure that CP15 barrier instructions are enabled, even
      if we enter the decompressor via the EFI stub.
      However, as it turns out, there are other ways in which we may end up
      using CP15 barrier instructions without them being enabled. I.e., when
      the decompressor startup code skips the cache_on() initially, we end
      up calling cache_clean_flush() with the caches and MMU off, in which
      case the CP15BEN bit in SCTLR may not be programmed either. And in
      fact, cache_on() itself issues CP15 barrier instructions before actually
      enabling them by programming the new SCTLR value (and issuing an ISB)
      Since these routines are shared between v7 CPUs and older ones that
      implement the CPUID extension as well, using the ordinary v7 barrier
      instructions in this code is not possible, and so we should enable the
      CP15 ones explicitly before issuing them. Note that a v7 ISB is still
      required between programming the SCTLR register and using the CP15 barrier
      instructions, and we should take care to branch over it if the CP15BEN
      bit is already set, given that in that case, the CPU may not support it.
      Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
  4. 23 Jan, 2020 21 commits