Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 01 3月, 2020 4 次提交
  3. 08 2月, 2020 1 次提交
  5. 04 2月, 2020 6 次提交
  7. 28 1月, 2020 4 次提交
  9. 27 1月, 2020 2 次提交
  11. 26 1月, 2020 8 次提交
    • V
      ARM: 8954/1: NOMMU: remove stubs for swapops · 03a575a6
      由 Vladimir Murzin 提交于 
      Stubs for swapops are not required after 9b98fa22 (mm: stub out
all of swapops.h for !CONFIG_MMU)
Signed-off-by: NVladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      03a575a6
    • V
      ARM: 8952/1: Disable kmemleak on XIP kernels · bc420c6c
      由 Vincenzo Frascino 提交于 
      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: NVincenzo Frascino <vincenzo.frascino@arm.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      bc420c6c
    • V
      ARM: 8951/1: Fix Kexec compilation issue. · 76950f71
      由 Vincenzo Frascino 提交于 
      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);
                         ^~~~~~~~~~~~
                         SECTIONS_WIDTH
  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'
     failed

Make KEXEC depend on MMU to fix the compilation issue.
Signed-off-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      76950f71
    • O
      ARM: 8949/1: mm: mark free_memmap as __init · 31f3010e
      由 Olof Johansson 提交于 
      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: NOlof Johansson <olof@lixom.net>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      31f3010e
    • V
      ARM: 8948/1: Prevent OOB access in stacktrace · 40ff1ddb
      由 Vincent Whitchurch 提交于 
      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.

Example:

 [<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: NVincent Whitchurch <vincent.whitchurch@axis.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      40ff1ddb
    • M
      ARM: 8945/1: decompressor: use CONFIG option instead of cc-option · 9db78852
      由 Masahiro Yamada 提交于 
      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: NMasahiro Yamada <masahiroy@kernel.org>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      9db78852
    • A
      ARM: 8942/1: Revert "8857/1: efi: enable CP15 DMB instructions before cleaning the cache" · cf17a1e3
      由 Ard Biesheuvel 提交于 
      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: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      cf17a1e3
    • A
      ARM: 8941/1: decompressor: enable CP15 barrier instructions in v7 cache setup code · 8239fc77
      由 Ard Biesheuvel 提交于 
      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: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      8239fc77
  13. 24 1月, 2020 15 次提交