linux-stable.git/arch/arm/kernel/setup.c, branch v4.19.78

ARM: spectre-v2: per-CPU vtables to work around big.Little systems

2019-02-20T09:25:38+00:00

Commit 383fb3ee8024d596f488d2dbaf45e572897acbdb upstream.

In big.Little systems, some CPUs require the Spectre workarounds in
paths such as the context switch, but other CPUs do not.  In order
to handle these differences, we need per-CPU vtables.

We are unable to use the kernel's per-CPU variables to support this
as per-CPU is not initialised at times when we need access to the
vtables, so we have to use an array indexed by logical CPU number.

We use an array-of-pointers to avoid having function pointers in
the kernel's read/write .data section.

Reviewed-by: Julien Thierry 
Signed-off-by: Russell King 
Signed-off-by: David A. Long 
Reviewed-by: Julien Thierry 
Tested-by: Julien Thierry 
Signed-off-by: Sasha Levin

ARM: add PROC_VTABLE and PROC_TABLE macros

2019-02-20T09:25:38+00:00

Commit e209950fdd065d2cc46e6338e47e52841b830cba upstream.

Allow the way we access members of the processor vtable to be changed
at compile time.  We will need to move to per-CPU vtables to fix the
Spectre variant 2 issues on big.Little systems.

However, we have a couple of calls that do not need the vtable
treatment, and indeed cause a kernel warning due to the (later) use
of smp_processor_id(), so also introduce the PROC_TABLE macro for
these which always use CPU 0's function pointers.

Reviewed-by: Julien Thierry 
Signed-off-by: Russell King 
Signed-off-by: David A. Long 
Reviewed-by: Julien Thierry 
Tested-by: Julien Thierry 
Signed-off-by: Sasha Levin

ARM: split out processor lookup

2019-02-20T09:25:38+00:00

Commit 65987a8553061515b5851b472081aedb9837a391 upstream.

Split out the lookup of the processor type and associated error handling
from the rest of setup_processor() - we will need to use this in the
secondary CPU bringup path for big.Little Spectre variant 2 mitigation.

Reviewed-by: Julien Thierry 
Signed-off-by: Russell King 
Signed-off-by: David A. Long 
Reviewed-by: Julien Thierry 
Tested-by: Julien Thierry 
Signed-off-by: Sasha Levin

ARM: Convert to GENERIC_IRQ_MULTI_HANDLER

2018-08-03T10:14:08+00:00

Converts the ARM interrupt code to use the recently added
GENERIC_IRQ_MULTI_HANDLER, which is essentially just a copy of ARM's
existhing MULTI_IRQ_HANDLER.  The only changes are:

* handle_arch_irq is now defined in a generic C file instead of an
  arm-specific assembly file.
 
* handle_arch_irq is now marked as __ro_after_init.

Signed-off-by: Palmer Dabbelt 
Signed-off-by: Thomas Gleixner 
Cc: linux@armlinux.org.uk
Cc: catalin.marinas@arm.com
Cc: Will Deacon 
Cc: jonas@southpole.se
Cc: stefan.kristiansson@saunalahti.fi
Cc: shorne@gmail.com
Cc: jason@lakedaemon.net
Cc: marc.zyngier@arm.com
Cc: Arnd Bergmann 
Cc: nicolas.pitre@linaro.org
Cc: vladimir.murzin@arm.com
Cc: keescook@chromium.org
Cc: jinb.park7@gmail.com
Cc: yamada.masahiro@socionext.com
Cc: alexandre.belloni@bootlin.com
Cc: pombredanne@nexb.com
Cc: Greg KH 
Cc: kstewart@linuxfoundation.org
Cc: jhogan@kernel.org
Cc: mark.rutland@arm.com
Cc: ard.biesheuvel@linaro.org
Cc: james.morse@arm.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: openrisc@lists.librecores.org
Link: https://lkml.kernel.org/r/20180622170126.6308-3-palmer@sifive.com

arch: remove the ARCH_PHYS_ADDR_T_64BIT config symbol

2018-05-09T04:56:33+00:00

Instead select the PHYS_ADDR_T_64BIT for 32-bit architectures that need a
64-bit phys_addr_t type directly.

Signed-off-by: Christoph Hellwig 
Acked-by: James Hogan

ARM: better diagnostics with missing/corrupt dtb

2017-09-29T12:57:21+00:00

With a kernel containing both DT and atag support, the diagnostics
output when the dtb is missing or corrupt assume that we're trying
to boot using atags and the machine ID, and only print the machine
ID.  This is not useful for diagnosing a missing or corrupt dtb.

Move the message into arch/arm/kernel/setup.c, and print the address
of the dtb/atag list, and the first 16 bytes of memory of the dtb or
atag list.

This allows us to see whether the dtb was corrupted in some way,
causing the fallback to the machine ID / atag list.

Tested-by: Keerthy 
Signed-off-by: Russell King

ARM: kexec: avoid allocating crashkernel region outside lowmem

2017-07-20T10:37:15+00:00

Allocating the crashkernel region outside lowmem causes the kernel to
oops while trying to kexec into the new kernel:

Loading crashdump kernel...
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = edd70000
[00000000] *pgd=de19e835
Internal error: Oops: 817 [#2] SMP ARM
Modules linked in: ...
CPU: 0 PID: 689 Comm: sh Not tainted 4.12.0-rc3-next-20170601-04015-gc3a5a20
Hardware name: Generic DRA74X (Flattened Device Tree)
task: edb32f00 task.stack: edf18000
PC is at memcpy+0x50/0x330
LR is at 0xe3c34001
pc : []    lr : []    psr: 800c0193
sp : edf19c2c  ip : 0a000001  fp : c0553170
r10: c055316e  r9 : 00000001  r8 : e3130001
r7 : e4903004  r6 : 0a000014  r5 : e3500000  r4 : e59f106c
r3 : e59f0074  r2 : ffffffe8  r1 : c010fb88  r0 : 00000000
Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: add7006a  DAC: 00000051
Process sh (pid: 689, stack limit = 0xedf18218)
Stack: (0xedf19c2c to 0xedf1a000)
...
[] (memcpy) from [] (machine_kexec+0xa8/0x12c)
[] (machine_kexec) from [] (__crash_kexec+0x5c/0x98)
[] (__crash_kexec) from [] (crash_kexec+0x5c/0x68)
[] (crash_kexec) from [] (die+0x228/0x490)
[] (die) from [] (__do_kernel_fault.part.0+0x54/0x1e4)
[] (__do_kernel_fault.part.0) from [] (do_page_fault+0x1e8/0x400)
[] (do_page_fault) from [] (do_DataAbort+0x38/0xb8)
[] (do_DataAbort) from [] (__dabt_svc+0x64/0xa0)

This is caused by image->control_code_page being a highmem page, so
page_address(image->control_code_page) returns NULL.  In any case, we
don't want the control page to be a highmem page.

We already limit the crash kernel region to the top of 32-bit physical
memory space.  Also limit it to the top of lowmem in physical space.

Reported-by: Keerthy 
Tested-by: Keerthy 
Signed-off-by: Russell King

ARM: 8682/1: V7M: Set cacheid iff DminLine or IminLine is nonzero

2017-06-12T14:47:29+00:00

Cache support is optional feature in M-class cores, thus DminLine or
IminLine of Cache Type Register is zero if caches are not implemented,
but we check the whole CTR which has other features encoded there.
Let's be more precise and check for DminLine and IminLine of CTR
before we set cacheid.

Signed-off-by: Vladimir Murzin 
Signed-off-by: Russell King

ARM: 8667/3: Fix memory attribute inconsistencies when using fixmap

2017-04-20T10:19:42+00:00

To cope with the variety in ARM architectures and configurations, the
pagetable attributes for kernel memory are generated at runtime to match
the system the kernel finds itself on. This calculated value is stored
in pgprot_kernel.

However, when early fixmap support was added for ARM (commit
a5f4c561b3b1) the attributes used for mappings were hard coded because
pgprot_kernel is not set up early enough. Unfortunately, when fixmap is
used after early boot this means the memory being mapped can have
different attributes to existing mappings, potentially leading to
unpredictable behaviour. A specific problem also exists due to the hard
coded values not include the 'shareable' attribute which means on
systems where this matters (e.g. those with multiple CPU clusters) the
cache contents for a memory location can become inconsistent between
CPUs.

To resolve these issues we change fixmap to use the same memory
attributes (from pgprot_kernel) that the rest of the kernel uses. To
enable this we need to refactor the initialisation code so
build_mem_type_table() is called early enough. Note, that relies on early
param parsing for memory type overrides passed via the kernel command
line, so we need to make sure this call is still after
parse_early_params().

[ardb: keep early_fixmap_init() before param parsing, for earlycon]

Fixes: a5f4c561b3b1 ("ARM: 8415/1: early fixmap support for earlycon")
Cc:  # v4.3+
Tested-by: afzal mohammed 
Signed-off-by: Jon Medhurst 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Russell King

ARM: 8637/1: Adjust memory boundaries after reservations

2017-02-28T11:05:28+00:00

adjust_lowmem_bounds is responsible for setting up the boundary for
lowmem/highmem. This needs to be setup before memblock reservations can
occur. At the time memblock reservations can occur, memory can also be
removed from the system. The lowmem/highmem boundary and end of memory
may be affected by this but it is currently not recalculated. On some
systems this may be harmless, on others this may result in incorrect
ranges being passed to the main memory allocator. Correct this by
recalculating the lowmem/highmem boundary after all reservations have
been made.

Tested-by: Magnus Lilja 
Signed-off-by: Laura Abbott 
Signed-off-by: Russell King