linux.git/arch/arm64/kernel/setup.c, branch v4.19 Linux kernel source tree arm64: Fix /proc/iomem for reserved but not memory regions 2018-10-12T14:25:16+00:00 Will Deacon will.deacon@arm.com 2018-10-11T10:29:14+00:00 d91680e687f47984ffd3200c8e5d587903e7bd11 We describe ranges of 'reserved' memory to userspace via /proc/iomem. Commit 50d7ba36b916 ("arm64: export memblock_reserve()d regions via /proc/iomem") updated the logic to export regions that were reserved because their contents should be preserved. This allowed kexec-tools to tell the difference between 'reserved' memory that must be preserved and not overwritten, (e.g. the ACPI tables), and 'nomap' memory that must not be touched without knowing the memory-attributes (e.g. RAS CPER regions). The above commit wrongly assumed that memblock_reserve() would not be used to reserve regions that aren't memory. It turns out this is exactly what early_init_dt_reserve_memory_arch() will do if it finds a DT reserved-memory that was also carved out of the memory node, which results in a WARN_ON_ONCE() and the region being reserved instead of ignored. The ramoops description on hikey and dragonboard-410c both do this, so we can't simply write this configuration off as "buggy firmware". Avoid this issue by rewriting reserve_memblock_reserved_regions() so that only the portions of reserved regions which overlap with mapped memory are actually reserved. Fixes: 50d7ba36b916 ("arm64: export memblock_reserve()d regions via /proc/iomem") Reported-by: John Stultz <john.stultz@linaro.org> Reported-by: Paolo Pisati <p.pisati@gmail.com> CC: Akashi Takahiro <takahiro.akashi@linaro.org> CC: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: James Morse <james.morse@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> 
We describe ranges of 'reserved' memory to userspace via /proc/iomem.
Commit 50d7ba36b916 ("arm64: export memblock_reserve()d regions via
/proc/iomem") updated the logic to export regions that were reserved
because their contents should be preserved. This allowed kexec-tools
to tell the difference between 'reserved' memory that must be
preserved and not overwritten, (e.g. the ACPI tables), and 'nomap'
memory that must not be touched without knowing the memory-attributes
(e.g. RAS CPER regions).

The above commit wrongly assumed that memblock_reserve() would not
be used to reserve regions that aren't memory. It turns out this is
exactly what early_init_dt_reserve_memory_arch() will do if it finds
a DT reserved-memory that was also carved out of the memory node, which
results in a WARN_ON_ONCE() and the region being reserved instead of
ignored. The ramoops description on hikey and dragonboard-410c both do
this, so we can't simply write this configuration off as "buggy firmware".

Avoid this issue by rewriting reserve_memblock_reserved_regions() so
that only the portions of reserved regions which overlap with mapped
memory are actually reserved.

Fixes: 50d7ba36b916 ("arm64: export memblock_reserve()d regions via /proc/iomem")
Reported-by: John Stultz <john.stultz@linaro.org>
Reported-by: Paolo Pisati <p.pisati@gmail.com>
CC: Akashi Takahiro <takahiro.akashi@linaro.org>
CC: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
arm64: export memblock_reserve()d regions via /proc/iomem 2018-07-23T14:30:32+00:00 James Morse james.morse@arm.com 2018-07-23T01:57:28+00:00 50d7ba36b916d0fd4687149ec143bf49c326523f There has been some confusion around what is necessary to prevent kexec overwriting important memory regions. memblock: reserve, or nomap? Only memblock nomap regions are reported via /proc/iomem, kexec's user-space doesn't know about memblock_reserve()d regions. Until commit f56ab9a5b73ca ("efi/arm: Don't mark ACPI reclaim memory as MEMBLOCK_NOMAP") the ACPI tables were nomap, now they are reserved and thus possible for kexec to overwrite with the new kernel or initrd. But this was always broken, as the UEFI memory map is also reserved and not marked as nomap. Exporting both nomap and reserved memblock types is a nuisance as they live in different memblock structures which we can't walk at the same time. Take a second walk over memblock.reserved and add new 'reserved' subnodes for the memblock_reserved() regions that aren't already described by the existing code. (e.g. Kernel Code) We use reserve_region_with_split() to find the gaps in existing named regions. This handles the gap between 'kernel code' and 'kernel data' which is memblock_reserve()d, but already partially described by request_standard_resources(). e.g.: | 80000000-dfffffff : System RAM | 80080000-80ffffff : Kernel code | 81000000-8158ffff : reserved | 81590000-8237efff : Kernel data | a0000000-dfffffff : Crash kernel | e00f0000-f949ffff : System RAM reserve_region_with_split needs kzalloc() which isn't available when request_standard_resources() is called, use an initcall. Reported-by: Bhupesh Sharma <bhsharma@redhat.com> Reported-by: Tyler Baicar <tbaicar@codeaurora.org> Suggested-by: Akashi Takahiro <takahiro.akashi@linaro.org> Signed-off-by: James Morse <james.morse@arm.com> Fixes: d28f6df1305a ("arm64/kexec: Add core kexec support") Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> CC: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> 
There has been some confusion around what is necessary to prevent kexec
overwriting important memory regions. memblock: reserve, or nomap?
Only memblock nomap regions are reported via /proc/iomem, kexec's
user-space doesn't know about memblock_reserve()d regions.

Until commit f56ab9a5b73ca ("efi/arm: Don't mark ACPI reclaim memory
as MEMBLOCK_NOMAP") the ACPI tables were nomap, now they are reserved
and thus possible for kexec to overwrite with the new kernel or initrd.
But this was always broken, as the UEFI memory map is also reserved
and not marked as nomap.

Exporting both nomap and reserved memblock types is a nuisance as
they live in different memblock structures which we can't walk at
the same time.

Take a second walk over memblock.reserved and add new 'reserved'
subnodes for the memblock_reserved() regions that aren't already
described by the existing code. (e.g. Kernel Code)

We use reserve_region_with_split() to find the gaps in existing named
regions. This handles the gap between 'kernel code' and 'kernel data'
which is memblock_reserve()d, but already partially described by
request_standard_resources(). e.g.:
| 80000000-dfffffff : System RAM
|   80080000-80ffffff : Kernel code
|   81000000-8158ffff : reserved
|   81590000-8237efff : Kernel data
|   a0000000-dfffffff : Crash kernel
| e00f0000-f949ffff : System RAM

reserve_region_with_split needs kzalloc() which isn't available when
request_standard_resources() is called, use an initcall.

Reported-by: Bhupesh Sharma <bhsharma@redhat.com>
Reported-by: Tyler Baicar <tbaicar@codeaurora.org>
Suggested-by: Akashi Takahiro <takahiro.akashi@linaro.org>
Signed-off-by: James Morse <james.morse@arm.com>
Fixes: d28f6df1305a ("arm64/kexec: Add core kexec support")
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
CC: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
arm64: Move the async/fiq helpers to explicitly set process context flags 2017-11-02T15:55:41+00:00 James Morse james.morse@arm.com 2017-11-02T12:12:36+00:00 41bd5b5d22b77c7300df2a2fa5397cbe785189b4 Remove the local_{async,fiq}_{en,dis}able macros as they don't respect our newly defined order and are only used to set the flags for process context when we bring CPUs online. Add a helper to do this. The IRQ flag varies as we want it masked on the boot CPU until we are ready to handle interrupts. The boot CPU unmasks SError during early boot once it can print an error message. If we can print an error message about SError, we can do the same for FIQ. Debug exceptions are already enabled by __cpu_setup(), which has also configured MDSCR_EL1 to disable MDE and KDE. Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Julien Thierry <julien.thierry@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> 
Remove the local_{async,fiq}_{en,dis}able macros as they don't respect
our newly defined order and are only used to set the flags for process
context when we bring CPUs online.

Add a helper to do this. The IRQ flag varies as we want it masked on
the boot CPU until we are ready to handle interrupts.
The boot CPU unmasks SError during early boot once it can print an error
message. If we can print an error message about SError, we can do the
same for FIQ. Debug exceptions are already enabled by __cpu_setup(),
which has also configured MDSCR_EL1 to disable MDE and KDE.

Signed-off-by: James Morse <james.morse@arm.com>
Reviewed-by: Julien Thierry <julien.thierry@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
arm64: consistently log boot/secondary CPU IDs 2017-10-04T12:42:52+00:00 Mark Rutland mark.rutland@arm.com 2017-09-27T13:50:38+00:00 ccaac16287f9b46c58777f5538c4ba3a9d4c3aeb Currently we inconsistently log identifying information for the boot CPU and secondary CPUs. For the boot CPU, we log the MIDR and MPIDR across separate messages, whereas for the secondary CPUs we only log the MIDR. In some cases, it would be useful to know the MPIDR of secondary CPUs, and it would be nice for these messages to be consistent. This patch ensures that in the primary and secondary boot paths, we log both the MPIDR and MIDR in a single message, with a consistent format. the MPIDR is consistently padded to 10 hex characters to cover Aff3 in bits 39:32, so that IDs can be compared easily. The newly redundant message in setup_arch() is removed. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Al Stone <ahs3@redhat.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> [will: added '0x' prefixes consistently] Signed-off-by: Will Deacon <will.deacon@arm.com> 
Currently we inconsistently log identifying information for the boot CPU
and secondary CPUs. For the boot CPU, we log the MIDR and MPIDR across
separate messages, whereas for the secondary CPUs we only log the MIDR.

In some cases, it would be useful to know the MPIDR of secondary CPUs,
and it would be nice for these messages to be consistent.

This patch ensures that in the primary and secondary boot paths, we log
both the MPIDR and MIDR in a single message, with a consistent format.
the MPIDR is consistently padded to 10 hex characters to cover Aff3 in
bits 39:32, so that IDs can be compared easily.

The newly redundant message in setup_arch() is removed.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Al Stone <ahs3@redhat.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
[will: added '0x' prefixes consistently]
Signed-off-by: Will Deacon <will.deacon@arm.com>
arm64: remove unneeded copy to init_utsname()->machine 2017-10-02T09:13:05+00:00 Masahiro Yamada yamada.masahiro@socionext.com 2017-09-14T11:40:04+00:00 c2f0b54f10b12620c57f6e31233589b704a00ed5 As you see in init/version.c, init_uts_ns.name.machine is initially set to UTS_MACHINE. There is no point to copy the same string. I dug the git history to figure out why this line is here. My best guess is like this: - This line has been around here since the initial support of arm64 by commit 9703d9d7f77c ("arm64: Kernel booting and initialisation"). If ARCH (=arm64) and UTS_MACHINE (=aarch64) do not match, arch/$(ARCH)/Makefile is supposed to override UTS_MACHINE, but the initial version of arch/arm64/Makefile missed to do that. Instead, the boot code copied "aarch64" to init_utsname()->machine. - Commit 94ed1f2cb5d4 ("arm64: setup: report ELF_PLATFORM as the machine for utsname") replaced "aarch64" with ELF_PLATFORM to make "uname" to reflect the endianness. - ELF_PLATFORM does not help to provide the UTS machine name to rpm target, so commit cfa88c79462d ("arm64: Set UTS_MACHINE in the Makefile") fixed it. The commit simply replaced ELF_PLATFORM with UTS_MACHINE, but missed the fact the string copy itself is no longer needed. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Will Deacon <will.deacon@arm.com> 
As you see in init/version.c, init_uts_ns.name.machine is initially
set to UTS_MACHINE.  There is no point to copy the same string.

I dug the git history to figure out why this line is here.  My best
guess is like this:

 - This line has been around here since the initial support of arm64
   by commit 9703d9d7f77c ("arm64: Kernel booting and initialisation").
   If ARCH (=arm64) and UTS_MACHINE (=aarch64) do not match,
   arch/$(ARCH)/Makefile is supposed to override UTS_MACHINE, but the
   initial version of arch/arm64/Makefile missed to do that.  Instead,
   the boot code copied "aarch64" to init_utsname()->machine.

 - Commit 94ed1f2cb5d4 ("arm64: setup: report ELF_PLATFORM as the
   machine for utsname") replaced "aarch64" with ELF_PLATFORM to
   make "uname" to reflect the endianness.

 - ELF_PLATFORM does not help to provide the UTS machine name to rpm
   target, so commit cfa88c79462d ("arm64: Set UTS_MACHINE in the
   Makefile") fixed it.  The commit simply replaced ELF_PLATFORM with
   UTS_MACHINE, but missed the fact the string copy itself is no longer
   needed.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
arm64: check return value of of_flat_dt_get_machine_name 2017-05-30T10:07:42+00:00 Kefeng Wang wangkefeng.wang@huawei.com 2017-05-16T07:36:16+00:00 690e95dd4d67be2eb905e1480b692c84e612a71a It's useless to print machine name and setup arch-specific system identifiers if of_flat_dt_get_machine_name() return NULL, especially when ACPI-based boot. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Will Deacon <will.deacon@arm.com> 
It's useless to print machine name and setup arch-specific system
identifiers if of_flat_dt_get_machine_name() return NULL, especially
when ACPI-based boot.

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
arm64: Print DT machine model in setup_machine_fdt() 2017-04-28T16:09:41+00:00 Geert Uytterhoeven geert+renesas@glider.be 2017-04-27T12:33:05+00:00 2f9a0bec659700554744338bf780841f641cec40 On arm32, the machine model specified in the device tree is printed during boot-up, courtesy of of_flat_dt_match_machine(). On arm64, of_flat_dt_match_machine() is not called, and the machine model information is not available from the kernel log. Print the machine model to make it easier to derive the machine model from an arbitrary kernel boot log. Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> 
On arm32, the machine model specified in the device tree is printed
during boot-up, courtesy of of_flat_dt_match_machine().

On arm64, of_flat_dt_match_machine() is not called, and the machine
model information is not available from the kernel log.

Print the machine model to make it easier to derive the machine model
from an arbitrary kernel boot log.

Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
arm64: kdump: reserve memory for crash dump kernel 2017-04-05T17:26:57+00:00 AKASHI Takahiro takahiro.akashi@linaro.org 2017-04-03T02:24:32+00:00 764b51ead10d5f428cb5f167bf98e336bdc23f8c "crashkernel=" kernel parameter specifies the size (and optionally the start address) of the system ram to be used by crash dump kernel. reserve_crashkernel() will allocate and reserve that memory at boot time of primary kernel. The memory range will be exposed to userspace as a resource named "Crash kernel" in /proc/iomem. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Signed-off-by: Mark Salter <msalter@redhat.com> Signed-off-by: Pratyush Anand <panand@redhat.com> Reviewed-by: James Morse <james.morse@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> 
"crashkernel=" kernel parameter specifies the size (and optionally
the start address) of the system ram to be used by crash dump kernel.
reserve_crashkernel() will allocate and reserve that memory at boot time
of primary kernel.

The memory range will be exposed to userspace as a resource named
"Crash kernel" in /proc/iomem.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Signed-off-by: Mark Salter <msalter@redhat.com>
Signed-off-by: Pratyush Anand <panand@redhat.com>
Reviewed-by: James Morse <james.morse@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
sched/headers: Prepare to move 'init_task' and 'init_thread_union' from <linux/sched.h> to <linux/sched/task.h> 2017-03-02T07:42:38+00:00 Ingo Molnar mingo@kernel.org 2017-02-04T00:20:53+00:00 9164bb4a18dfa592cd0aca455ea57abf89ca4526 Update all usage sites first. Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> 
Update all usage sites first.

Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
arm64: kernel: do not mark reserved memory regions as IORESOURCE_BUSY 2017-01-26T12:15:13+00:00 Ard Biesheuvel ard.biesheuvel@linaro.org 2017-01-24T17:11:40+00:00 79ba11d24b28ead94b976c4d7c8bf8e6c349eb36 Memory regions marked as NOMAP should not be used for general allocation by the kernel, and should not even be covered by the linear mapping (hence the name). However, drivers or other subsystems (such as ACPI) that access the firmware directly may legally access them, which means it is also reasonable for such drivers to claim them by invoking request_resource(). Currently, this is prevented by the fact that arm64's request_standard_resources() marks reserved regions as IORESOURCE_BUSY. So drop the IORESOURCE_BUSY flag from these requests. Reported-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> 
Memory regions marked as NOMAP should not be used for general allocation
by the kernel, and should not even be covered by the linear mapping
(hence the name). However, drivers or other subsystems (such as ACPI)
that access the firmware directly may legally access them, which means
it is also reasonable for such drivers to claim them by invoking
request_resource(). Currently, this is prevented by the fact that arm64's
request_standard_resources() marks reserved regions as IORESOURCE_BUSY.

So drop the IORESOURCE_BUSY flag from these requests.

Reported-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>