summaryrefslogtreecommitdiff
path: root/mm/list_lru.c
diff options
context:
space:
mode:
authorWill Deacon <will.deacon@arm.com>2018-10-11 11:29:14 +0100
committerWill Deacon <will.deacon@arm.com>2018-10-12 15:25:16 +0100
commitd91680e687f47984ffd3200c8e5d587903e7bd11 (patch)
tree1d76fe99328e0a6439b8163e508fcca1df44cb97 /mm/list_lru.c
parent0238df646e6224016a45505d2c111a24669ebe21 (diff)
arm64: Fix /proc/iomem for reserved but not memory regions
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>
Diffstat (limited to 'mm/list_lru.c')
0 files changed, 0 insertions, 0 deletions