2012-03-05 11:49:27 +00:00
|
|
|
/*
|
|
|
|
* Based on arch/arm/mm/init.c
|
|
|
|
*
|
|
|
|
* Copyright (C) 1995-2005 Russell King
|
|
|
|
* Copyright (C) 2012 ARM Ltd.
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License version 2 as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/export.h>
|
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/swap.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/bootmem.h>
|
2016-08-15 06:45:46 +00:00
|
|
|
#include <linux/cache.h>
|
2012-03-05 11:49:27 +00:00
|
|
|
#include <linux/mman.h>
|
|
|
|
#include <linux/nodemask.h>
|
|
|
|
#include <linux/initrd.h>
|
|
|
|
#include <linux/gfp.h>
|
|
|
|
#include <linux/memblock.h>
|
|
|
|
#include <linux/sort.h>
|
|
|
|
#include <linux/of_fdt.h>
|
2014-02-27 12:09:22 +00:00
|
|
|
#include <linux/dma-mapping.h>
|
2013-12-12 19:28:33 +00:00
|
|
|
#include <linux/dma-contiguous.h>
|
2014-07-28 18:03:03 +00:00
|
|
|
#include <linux/efi.h>
|
2015-02-05 18:01:53 +00:00
|
|
|
#include <linux/swiotlb.h>
|
2016-09-05 11:30:22 +00:00
|
|
|
#include <linux/vmalloc.h>
|
2017-01-10 21:35:49 +00:00
|
|
|
#include <linux/mm.h>
|
2012-03-05 11:49:27 +00:00
|
|
|
|
2016-02-16 12:52:42 +00:00
|
|
|
#include <asm/boot.h>
|
2014-07-16 16:42:43 +00:00
|
|
|
#include <asm/fixmap.h>
|
2016-02-16 12:52:40 +00:00
|
|
|
#include <asm/kasan.h>
|
2016-02-16 12:52:42 +00:00
|
|
|
#include <asm/kernel-pgtable.h>
|
arm64: Fix overlapping VA allocations
PCI IO space was intended to be 16MiB, at 32MiB below MODULES_VADDR, but
commit d1e6dc91b532d3d3 ("arm64: Add architectural support for PCI")
extended this to cover the full 32MiB. The final 8KiB of this 32MiB is
also allocated for the fixmap, allowing for potential clashes between
the two.
This change was masked by assumptions in mem_init and the page table
dumping code, which assumed the I/O space to be 16MiB long through
seaparte hard-coded definitions.
This patch changes the definition of the PCI I/O space allocation to
live in asm/memory.h, along with the other VA space allocations. As the
fixmap allocation depends on the number of fixmap entries, this is moved
below the PCI I/O space allocation. Both the fixmap and PCI I/O space
are guarded with 2MB of padding. Sites assuming the I/O space was 16MiB
are moved over use new PCI_IO_{START,END} definitions, which will keep
in sync with the size of the IO space (now restored to 16MiB).
As a useful side effect, the use of the new PCI_IO_{START,END}
definitions prevents a build issue in the dumping code due to a (now
redundant) missing include of io.h for PCI_IOBASE.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Laura Abbott <lauraa@codeaurora.org>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Steve Capper <steve.capper@linaro.org>
Cc: Will Deacon <will.deacon@arm.com>
[catalin.marinas@arm.com: reorder FIXADDR and PCI_IO address_markers_idx enum]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2015-01-22 18:20:35 +00:00
|
|
|
#include <asm/memory.h>
|
2016-04-08 22:50:27 +00:00
|
|
|
#include <asm/numa.h>
|
2012-03-05 11:49:27 +00:00
|
|
|
#include <asm/sections.h>
|
|
|
|
#include <asm/setup.h>
|
|
|
|
#include <asm/sizes.h>
|
|
|
|
#include <asm/tlb.h>
|
2014-11-14 15:54:08 +00:00
|
|
|
#include <asm/alternative.h>
|
2012-03-05 11:49:27 +00:00
|
|
|
|
2016-02-16 12:52:42 +00:00
|
|
|
/*
|
|
|
|
* We need to be able to catch inadvertent references to memstart_addr
|
|
|
|
* that occur (potentially in generic code) before arm64_memblock_init()
|
|
|
|
* executes, which assigns it its actual value. So use a default value
|
|
|
|
* that cannot be mistaken for a real physical address.
|
|
|
|
*/
|
2016-08-15 06:45:46 +00:00
|
|
|
s64 memstart_addr __ro_after_init = -1;
|
|
|
|
phys_addr_t arm64_dma_phys_limit __ro_after_init;
|
2012-03-05 11:49:27 +00:00
|
|
|
|
2013-08-25 21:47:48 +00:00
|
|
|
#ifdef CONFIG_BLK_DEV_INITRD
|
2012-03-05 11:49:27 +00:00
|
|
|
static int __init early_initrd(char *p)
|
|
|
|
{
|
|
|
|
unsigned long start, size;
|
|
|
|
char *endp;
|
|
|
|
|
|
|
|
start = memparse(p, &endp);
|
|
|
|
if (*endp == ',') {
|
|
|
|
size = memparse(endp + 1, NULL);
|
|
|
|
|
2016-02-16 12:52:41 +00:00
|
|
|
initrd_start = start;
|
|
|
|
initrd_end = start + size;
|
2012-03-05 11:49:27 +00:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
early_param("initrd", early_initrd);
|
2013-08-25 21:47:48 +00:00
|
|
|
#endif
|
2012-03-05 11:49:27 +00:00
|
|
|
|
2014-07-18 10:54:37 +00:00
|
|
|
/*
|
|
|
|
* Return the maximum physical address for ZONE_DMA (DMA_BIT_MASK(32)). It
|
|
|
|
* currently assumes that for memory starting above 4G, 32-bit devices will
|
|
|
|
* use a DMA offset.
|
|
|
|
*/
|
2015-11-20 09:59:10 +00:00
|
|
|
static phys_addr_t __init max_zone_dma_phys(void)
|
2014-07-18 10:54:37 +00:00
|
|
|
{
|
|
|
|
phys_addr_t offset = memblock_start_of_DRAM() & GENMASK_ULL(63, 32);
|
|
|
|
return min(offset + (1ULL << 32), memblock_end_of_DRAM());
|
|
|
|
}
|
|
|
|
|
2016-04-08 22:50:27 +00:00
|
|
|
#ifdef CONFIG_NUMA
|
|
|
|
|
|
|
|
static void __init zone_sizes_init(unsigned long min, unsigned long max)
|
|
|
|
{
|
|
|
|
unsigned long max_zone_pfns[MAX_NR_ZONES] = {0};
|
|
|
|
|
|
|
|
if (IS_ENABLED(CONFIG_ZONE_DMA))
|
|
|
|
max_zone_pfns[ZONE_DMA] = PFN_DOWN(max_zone_dma_phys());
|
|
|
|
max_zone_pfns[ZONE_NORMAL] = max;
|
|
|
|
|
|
|
|
free_area_init_nodes(max_zone_pfns);
|
|
|
|
}
|
|
|
|
|
|
|
|
#else
|
|
|
|
|
2012-03-05 11:49:27 +00:00
|
|
|
static void __init zone_sizes_init(unsigned long min, unsigned long max)
|
|
|
|
{
|
|
|
|
struct memblock_region *reg;
|
|
|
|
unsigned long zone_size[MAX_NR_ZONES], zhole_size[MAX_NR_ZONES];
|
2014-02-27 12:09:22 +00:00
|
|
|
unsigned long max_dma = min;
|
2012-03-05 11:49:27 +00:00
|
|
|
|
|
|
|
memset(zone_size, 0, sizeof(zone_size));
|
|
|
|
|
|
|
|
/* 4GB maximum for 32-bit only capable devices */
|
2015-10-27 17:40:26 +00:00
|
|
|
#ifdef CONFIG_ZONE_DMA
|
|
|
|
max_dma = PFN_DOWN(arm64_dma_phys_limit);
|
|
|
|
zone_size[ZONE_DMA] = max_dma - min;
|
|
|
|
#endif
|
2014-02-27 12:09:22 +00:00
|
|
|
zone_size[ZONE_NORMAL] = max - max_dma;
|
2012-03-05 11:49:27 +00:00
|
|
|
|
|
|
|
memcpy(zhole_size, zone_size, sizeof(zhole_size));
|
|
|
|
|
|
|
|
for_each_memblock(memory, reg) {
|
|
|
|
unsigned long start = memblock_region_memory_base_pfn(reg);
|
|
|
|
unsigned long end = memblock_region_memory_end_pfn(reg);
|
|
|
|
|
|
|
|
if (start >= max)
|
|
|
|
continue;
|
2014-02-27 12:09:22 +00:00
|
|
|
|
2015-10-27 17:40:26 +00:00
|
|
|
#ifdef CONFIG_ZONE_DMA
|
|
|
|
if (start < max_dma) {
|
2014-02-27 12:09:22 +00:00
|
|
|
unsigned long dma_end = min(end, max_dma);
|
|
|
|
zhole_size[ZONE_DMA] -= dma_end - start;
|
2012-03-05 11:49:27 +00:00
|
|
|
}
|
2015-10-27 17:40:26 +00:00
|
|
|
#endif
|
2014-02-27 12:09:22 +00:00
|
|
|
if (end > max_dma) {
|
2012-03-05 11:49:27 +00:00
|
|
|
unsigned long normal_end = min(end, max);
|
2014-02-27 12:09:22 +00:00
|
|
|
unsigned long normal_start = max(start, max_dma);
|
2012-03-05 11:49:27 +00:00
|
|
|
zhole_size[ZONE_NORMAL] -= normal_end - normal_start;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
free_area_init_node(0, zone_size, min, zhole_size);
|
|
|
|
}
|
|
|
|
|
2016-04-08 22:50:27 +00:00
|
|
|
#endif /* CONFIG_NUMA */
|
|
|
|
|
2012-03-05 11:49:27 +00:00
|
|
|
#ifdef CONFIG_HAVE_ARCH_PFN_VALID
|
|
|
|
int pfn_valid(unsigned long pfn)
|
|
|
|
{
|
2015-11-30 12:28:16 +00:00
|
|
|
return memblock_is_map_memory(pfn << PAGE_SHIFT);
|
2012-03-05 11:49:27 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(pfn_valid);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifndef CONFIG_SPARSEMEM
|
2015-11-20 09:59:10 +00:00
|
|
|
static void __init arm64_memory_present(void)
|
2012-03-05 11:49:27 +00:00
|
|
|
{
|
|
|
|
}
|
|
|
|
#else
|
2015-11-20 09:59:10 +00:00
|
|
|
static void __init arm64_memory_present(void)
|
2012-03-05 11:49:27 +00:00
|
|
|
{
|
|
|
|
struct memblock_region *reg;
|
|
|
|
|
2016-04-08 22:50:27 +00:00
|
|
|
for_each_memblock(memory, reg) {
|
2016-06-22 11:13:45 +00:00
|
|
|
int nid = memblock_get_region_node(reg);
|
|
|
|
|
2016-04-08 22:50:27 +00:00
|
|
|
memory_present(nid, memblock_region_memory_base_pfn(reg),
|
|
|
|
memblock_region_memory_end_pfn(reg));
|
|
|
|
}
|
2012-03-05 11:49:27 +00:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2015-01-15 16:42:14 +00:00
|
|
|
static phys_addr_t memory_limit = (phys_addr_t)ULLONG_MAX;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Limit the memory size that was specified via FDT.
|
|
|
|
*/
|
|
|
|
static int __init early_mem(char *p)
|
|
|
|
{
|
|
|
|
if (!p)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
memory_limit = memparse(p, &p) & PAGE_MASK;
|
|
|
|
pr_notice("Memory limited to %lldMB\n", memory_limit >> 20);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
early_param("mem", early_mem);
|
|
|
|
|
2012-03-05 11:49:27 +00:00
|
|
|
void __init arm64_memblock_init(void)
|
|
|
|
{
|
2016-02-16 12:52:42 +00:00
|
|
|
const s64 linear_region_size = -(s64)PAGE_OFFSET;
|
|
|
|
|
2016-03-02 08:47:13 +00:00
|
|
|
/*
|
|
|
|
* Ensure that the linear region takes up exactly half of the kernel
|
|
|
|
* virtual address space. This way, we can distinguish a linear address
|
|
|
|
* from a kernel/module/vmalloc address by testing a single bit.
|
|
|
|
*/
|
|
|
|
BUILD_BUG_ON(linear_region_size != BIT(VA_BITS - 1));
|
|
|
|
|
2016-02-16 12:52:42 +00:00
|
|
|
/*
|
|
|
|
* Select a suitable value for the base of physical memory.
|
|
|
|
*/
|
|
|
|
memstart_addr = round_down(memblock_start_of_DRAM(),
|
|
|
|
ARM64_MEMSTART_ALIGN);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Remove the memory that we will not be able to cover with the
|
|
|
|
* linear mapping. Take care not to clip the kernel which may be
|
|
|
|
* high in memory.
|
|
|
|
*/
|
2017-01-10 21:35:49 +00:00
|
|
|
memblock_remove(max_t(u64, memstart_addr + linear_region_size,
|
|
|
|
__pa_symbol(_end)), ULLONG_MAX);
|
2016-03-30 12:25:46 +00:00
|
|
|
if (memstart_addr + linear_region_size < memblock_end_of_DRAM()) {
|
|
|
|
/* ensure that memstart_addr remains sufficiently aligned */
|
|
|
|
memstart_addr = round_up(memblock_end_of_DRAM() - linear_region_size,
|
|
|
|
ARM64_MEMSTART_ALIGN);
|
|
|
|
memblock_remove(0, memstart_addr);
|
|
|
|
}
|
2016-02-16 12:52:42 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Apply the memory limit if it was set. Since the kernel may be loaded
|
|
|
|
* high up in memory, add back the kernel region that must be accessible
|
|
|
|
* via the linear mapping.
|
|
|
|
*/
|
|
|
|
if (memory_limit != (phys_addr_t)ULLONG_MAX) {
|
2016-07-28 22:48:29 +00:00
|
|
|
memblock_mem_limit_remove_map(memory_limit);
|
2017-01-10 21:35:49 +00:00
|
|
|
memblock_add(__pa_symbol(_text), (u64)(_end - _text));
|
2016-02-16 12:52:42 +00:00
|
|
|
}
|
2015-01-15 16:42:14 +00:00
|
|
|
|
2016-03-30 13:18:42 +00:00
|
|
|
if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && initrd_start) {
|
|
|
|
/*
|
|
|
|
* Add back the memory we just removed if it results in the
|
|
|
|
* initrd to become inaccessible via the linear mapping.
|
|
|
|
* Otherwise, this is a no-op
|
|
|
|
*/
|
|
|
|
u64 base = initrd_start & PAGE_MASK;
|
|
|
|
u64 size = PAGE_ALIGN(initrd_end) - base;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We can only add back the initrd memory if we don't end up
|
|
|
|
* with more memory than we can address via the linear mapping.
|
|
|
|
* It is up to the bootloader to position the kernel and the
|
|
|
|
* initrd reasonably close to each other (i.e., within 32 GB of
|
|
|
|
* each other) so that all granule/#levels combinations can
|
|
|
|
* always access both.
|
|
|
|
*/
|
|
|
|
if (WARN(base < memblock_start_of_DRAM() ||
|
|
|
|
base + size > memblock_start_of_DRAM() +
|
|
|
|
linear_region_size,
|
|
|
|
"initrd not fully accessible via the linear mapping -- please check your bootloader ...\n")) {
|
|
|
|
initrd_start = 0;
|
|
|
|
} else {
|
|
|
|
memblock_remove(base, size); /* clear MEMBLOCK_ flags */
|
|
|
|
memblock_add(base, size);
|
|
|
|
memblock_reserve(base, size);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-01-29 10:59:03 +00:00
|
|
|
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
|
|
|
|
extern u16 memstart_offset_seed;
|
|
|
|
u64 range = linear_region_size -
|
|
|
|
(memblock_end_of_DRAM() - memblock_start_of_DRAM());
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the size of the linear region exceeds, by a sufficient
|
|
|
|
* margin, the size of the region that the available physical
|
|
|
|
* memory spans, randomize the linear region as well.
|
|
|
|
*/
|
|
|
|
if (memstart_offset_seed > 0 && range >= ARM64_MEMSTART_ALIGN) {
|
|
|
|
range = range / ARM64_MEMSTART_ALIGN + 1;
|
|
|
|
memstart_addr -= ARM64_MEMSTART_ALIGN *
|
|
|
|
((range * memstart_offset_seed) >> 16);
|
|
|
|
}
|
|
|
|
}
|
2015-01-15 16:42:14 +00:00
|
|
|
|
2014-06-24 15:51:35 +00:00
|
|
|
/*
|
|
|
|
* Register the kernel text, kernel data, initrd, and initial
|
|
|
|
* pagetables with memblock.
|
|
|
|
*/
|
2017-01-10 21:35:49 +00:00
|
|
|
memblock_reserve(__pa_symbol(_text), _end - _text);
|
2012-03-05 11:49:27 +00:00
|
|
|
#ifdef CONFIG_BLK_DEV_INITRD
|
2016-02-16 12:52:41 +00:00
|
|
|
if (initrd_start) {
|
|
|
|
memblock_reserve(initrd_start, initrd_end - initrd_start);
|
|
|
|
|
|
|
|
/* the generic initrd code expects virtual addresses */
|
|
|
|
initrd_start = __phys_to_virt(initrd_start);
|
|
|
|
initrd_end = __phys_to_virt(initrd_end);
|
|
|
|
}
|
2012-03-05 11:49:27 +00:00
|
|
|
#endif
|
|
|
|
|
2014-09-08 17:01:08 +00:00
|
|
|
early_init_fdt_scan_reserved_mem();
|
2014-06-13 12:41:20 +00:00
|
|
|
|
|
|
|
/* 4GB maximum for 32-bit only capable devices */
|
|
|
|
if (IS_ENABLED(CONFIG_ZONE_DMA))
|
2015-02-05 18:01:53 +00:00
|
|
|
arm64_dma_phys_limit = max_zone_dma_phys();
|
|
|
|
else
|
|
|
|
arm64_dma_phys_limit = PHYS_MASK + 1;
|
|
|
|
dma_contiguous_reserve(arm64_dma_phys_limit);
|
2013-12-12 19:28:33 +00:00
|
|
|
|
2012-03-05 11:49:27 +00:00
|
|
|
memblock_allow_resize();
|
|
|
|
}
|
|
|
|
|
|
|
|
void __init bootmem_init(void)
|
|
|
|
{
|
|
|
|
unsigned long min, max;
|
|
|
|
|
|
|
|
min = PFN_UP(memblock_start_of_DRAM());
|
|
|
|
max = PFN_DOWN(memblock_end_of_DRAM());
|
|
|
|
|
2015-04-14 22:48:33 +00:00
|
|
|
early_memtest(min << PAGE_SHIFT, max << PAGE_SHIFT);
|
|
|
|
|
2016-04-08 22:50:27 +00:00
|
|
|
max_pfn = max_low_pfn = max;
|
|
|
|
|
|
|
|
arm64_numa_init();
|
2012-03-05 11:49:27 +00:00
|
|
|
/*
|
|
|
|
* Sparsemem tries to allocate bootmem in memory_present(), so must be
|
|
|
|
* done after the fixed reservations.
|
|
|
|
*/
|
|
|
|
arm64_memory_present();
|
|
|
|
|
|
|
|
sparse_init();
|
|
|
|
zone_sizes_init(min, max);
|
|
|
|
|
|
|
|
high_memory = __va((max << PAGE_SHIFT) - 1) + 1;
|
2016-04-08 22:50:27 +00:00
|
|
|
memblock_dump_all();
|
2012-03-05 11:49:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#ifndef CONFIG_SPARSEMEM_VMEMMAP
|
|
|
|
static inline void free_memmap(unsigned long start_pfn, unsigned long end_pfn)
|
|
|
|
{
|
|
|
|
struct page *start_pg, *end_pg;
|
|
|
|
unsigned long pg, pgend;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Convert start_pfn/end_pfn to a struct page pointer.
|
|
|
|
*/
|
|
|
|
start_pg = pfn_to_page(start_pfn - 1) + 1;
|
|
|
|
end_pg = pfn_to_page(end_pfn - 1) + 1;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Convert to physical addresses, and round start upwards and end
|
|
|
|
* downwards.
|
|
|
|
*/
|
|
|
|
pg = (unsigned long)PAGE_ALIGN(__pa(start_pg));
|
|
|
|
pgend = (unsigned long)__pa(end_pg) & PAGE_MASK;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If there are free pages between these, free the section of the
|
|
|
|
* memmap array.
|
|
|
|
*/
|
|
|
|
if (pg < pgend)
|
|
|
|
free_bootmem(pg, pgend - pg);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The mem_map array can get very big. Free the unused area of the memory map.
|
|
|
|
*/
|
|
|
|
static void __init free_unused_memmap(void)
|
|
|
|
{
|
|
|
|
unsigned long start, prev_end = 0;
|
|
|
|
struct memblock_region *reg;
|
|
|
|
|
|
|
|
for_each_memblock(memory, reg) {
|
|
|
|
start = __phys_to_pfn(reg->base);
|
|
|
|
|
|
|
|
#ifdef CONFIG_SPARSEMEM
|
|
|
|
/*
|
|
|
|
* Take care not to free memmap entries that don't exist due
|
|
|
|
* to SPARSEMEM sections which aren't present.
|
|
|
|
*/
|
|
|
|
start = min(start, ALIGN(prev_end, PAGES_PER_SECTION));
|
|
|
|
#endif
|
|
|
|
/*
|
|
|
|
* If we had a previous bank, and there is a space between the
|
|
|
|
* current bank and the previous, free it.
|
|
|
|
*/
|
|
|
|
if (prev_end && prev_end < start)
|
|
|
|
free_memmap(prev_end, start);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Align up here since the VM subsystem insists that the
|
|
|
|
* memmap entries are valid from the bank end aligned to
|
|
|
|
* MAX_ORDER_NR_PAGES.
|
|
|
|
*/
|
2015-06-16 16:38:47 +00:00
|
|
|
prev_end = ALIGN(__phys_to_pfn(reg->base + reg->size),
|
2012-03-05 11:49:27 +00:00
|
|
|
MAX_ORDER_NR_PAGES);
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_SPARSEMEM
|
|
|
|
if (!IS_ALIGNED(prev_end, PAGES_PER_SECTION))
|
|
|
|
free_memmap(prev_end, ALIGN(prev_end, PAGES_PER_SECTION));
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
#endif /* !CONFIG_SPARSEMEM_VMEMMAP */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* mem_init() marks the free areas in the mem_map and tells us how much memory
|
|
|
|
* is free. This is done after various parts of the system have claimed their
|
|
|
|
* memory after the kernel image.
|
|
|
|
*/
|
|
|
|
void __init mem_init(void)
|
|
|
|
{
|
2016-12-16 13:28:41 +00:00
|
|
|
if (swiotlb_force == SWIOTLB_FORCE ||
|
|
|
|
max_pfn > (arm64_dma_phys_limit >> PAGE_SHIFT))
|
2016-06-08 07:53:46 +00:00
|
|
|
swiotlb_init(1);
|
2017-01-16 11:46:33 +00:00
|
|
|
else
|
|
|
|
swiotlb_force = SWIOTLB_NO_FORCE;
|
2015-02-05 18:01:53 +00:00
|
|
|
|
2014-09-16 17:53:54 +00:00
|
|
|
set_max_mapnr(pfn_to_page(max_pfn) - mem_map);
|
2012-03-05 11:49:27 +00:00
|
|
|
|
|
|
|
#ifndef CONFIG_SPARSEMEM_VMEMMAP
|
|
|
|
free_unused_memmap();
|
|
|
|
#endif
|
2013-07-03 22:03:49 +00:00
|
|
|
/* this will put all unused low memory onto the freelists */
|
2013-07-03 22:03:24 +00:00
|
|
|
free_all_bootmem();
|
2012-03-05 11:49:27 +00:00
|
|
|
|
2013-07-03 22:04:02 +00:00
|
|
|
mem_init_print_info(NULL);
|
2012-03-05 11:49:27 +00:00
|
|
|
|
|
|
|
#define MLK(b, t) b, t, ((t) - (b)) >> 10
|
|
|
|
#define MLM(b, t) b, t, ((t) - (b)) >> 20
|
2014-07-16 16:42:43 +00:00
|
|
|
#define MLG(b, t) b, t, ((t) - (b)) >> 30
|
2012-03-05 11:49:27 +00:00
|
|
|
#define MLK_ROUNDUP(b, t) b, t, DIV_ROUND_UP(((t) - (b)), SZ_1K)
|
|
|
|
|
2016-03-11 17:39:25 +00:00
|
|
|
pr_notice("Virtual kernel memory layout:\n");
|
2015-10-12 15:52:59 +00:00
|
|
|
#ifdef CONFIG_KASAN
|
arm64: remove pr_cont abuse from mem_init
All the lines printed by mem_init are independent, with each ending with
a newline. While they logically form a large block, none are actually
continuations of previous lines.
The kernel-side printk code and the userspace demsg tool differ in their
handling of KERN_CONT following a newline, and while this isn't always a
problem kernel-side, it does cause difficulty for userspace. Using
pr_cont causes the userspace tool to not print line prefix (e.g.
timestamps) even when following a newline, mis-aligning the output and
making it harder to read, e.g.
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000 ( 128 MB)
vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000 (129022 GB)
.text : 0xffff000008080000 - 0xffff0000088b0000 ( 8384 KB)
.rodata : 0xffff0000088b0000 - 0xffff000008c50000 ( 3712 KB)
.init : 0xffff000008c50000 - 0xffff000008d50000 ( 1024 KB)
.data : 0xffff000008d50000 - 0xffff000008e25200 ( 853 KB)
.bss : 0xffff000008e25200 - 0xffff000008e6bec0 ( 284 KB)
fixed : 0xffff7dfffe7fd000 - 0xffff7dfffec00000 ( 4108 KB)
PCI I/O : 0xffff7dfffee00000 - 0xffff7dffffe00000 ( 16 MB)
vmemmap : 0xffff7e0000000000 - 0xffff800000000000 ( 2048 GB maximum)
0xffff7e0000000000 - 0xffff7e0026000000 ( 608 MB actual)
memory : 0xffff800000000000 - 0xffff800980000000 ( 38912 MB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
Fix this by using pr_notice consistently for all lines, which both the
kernel and userspace are happy with.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-20 11:24:53 +00:00
|
|
|
pr_notice(" kasan : 0x%16lx - 0x%16lx (%6ld GB)\n",
|
2016-03-11 17:39:25 +00:00
|
|
|
MLG(KASAN_SHADOW_START, KASAN_SHADOW_END));
|
2015-10-12 15:52:59 +00:00
|
|
|
#endif
|
arm64: remove pr_cont abuse from mem_init
All the lines printed by mem_init are independent, with each ending with
a newline. While they logically form a large block, none are actually
continuations of previous lines.
The kernel-side printk code and the userspace demsg tool differ in their
handling of KERN_CONT following a newline, and while this isn't always a
problem kernel-side, it does cause difficulty for userspace. Using
pr_cont causes the userspace tool to not print line prefix (e.g.
timestamps) even when following a newline, mis-aligning the output and
making it harder to read, e.g.
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000 ( 128 MB)
vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000 (129022 GB)
.text : 0xffff000008080000 - 0xffff0000088b0000 ( 8384 KB)
.rodata : 0xffff0000088b0000 - 0xffff000008c50000 ( 3712 KB)
.init : 0xffff000008c50000 - 0xffff000008d50000 ( 1024 KB)
.data : 0xffff000008d50000 - 0xffff000008e25200 ( 853 KB)
.bss : 0xffff000008e25200 - 0xffff000008e6bec0 ( 284 KB)
fixed : 0xffff7dfffe7fd000 - 0xffff7dfffec00000 ( 4108 KB)
PCI I/O : 0xffff7dfffee00000 - 0xffff7dffffe00000 ( 16 MB)
vmemmap : 0xffff7e0000000000 - 0xffff800000000000 ( 2048 GB maximum)
0xffff7e0000000000 - 0xffff7e0026000000 ( 608 MB actual)
memory : 0xffff800000000000 - 0xffff800980000000 ( 38912 MB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
Fix this by using pr_notice consistently for all lines, which both the
kernel and userspace are happy with.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-20 11:24:53 +00:00
|
|
|
pr_notice(" modules : 0x%16lx - 0x%16lx (%6ld MB)\n",
|
2016-03-11 17:39:25 +00:00
|
|
|
MLM(MODULES_VADDR, MODULES_END));
|
arm64: remove pr_cont abuse from mem_init
All the lines printed by mem_init are independent, with each ending with
a newline. While they logically form a large block, none are actually
continuations of previous lines.
The kernel-side printk code and the userspace demsg tool differ in their
handling of KERN_CONT following a newline, and while this isn't always a
problem kernel-side, it does cause difficulty for userspace. Using
pr_cont causes the userspace tool to not print line prefix (e.g.
timestamps) even when following a newline, mis-aligning the output and
making it harder to read, e.g.
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000 ( 128 MB)
vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000 (129022 GB)
.text : 0xffff000008080000 - 0xffff0000088b0000 ( 8384 KB)
.rodata : 0xffff0000088b0000 - 0xffff000008c50000 ( 3712 KB)
.init : 0xffff000008c50000 - 0xffff000008d50000 ( 1024 KB)
.data : 0xffff000008d50000 - 0xffff000008e25200 ( 853 KB)
.bss : 0xffff000008e25200 - 0xffff000008e6bec0 ( 284 KB)
fixed : 0xffff7dfffe7fd000 - 0xffff7dfffec00000 ( 4108 KB)
PCI I/O : 0xffff7dfffee00000 - 0xffff7dffffe00000 ( 16 MB)
vmemmap : 0xffff7e0000000000 - 0xffff800000000000 ( 2048 GB maximum)
0xffff7e0000000000 - 0xffff7e0026000000 ( 608 MB actual)
memory : 0xffff800000000000 - 0xffff800980000000 ( 38912 MB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
Fix this by using pr_notice consistently for all lines, which both the
kernel and userspace are happy with.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-20 11:24:53 +00:00
|
|
|
pr_notice(" vmalloc : 0x%16lx - 0x%16lx (%6ld GB)\n",
|
2016-03-11 17:39:25 +00:00
|
|
|
MLG(VMALLOC_START, VMALLOC_END));
|
arm64: remove pr_cont abuse from mem_init
All the lines printed by mem_init are independent, with each ending with
a newline. While they logically form a large block, none are actually
continuations of previous lines.
The kernel-side printk code and the userspace demsg tool differ in their
handling of KERN_CONT following a newline, and while this isn't always a
problem kernel-side, it does cause difficulty for userspace. Using
pr_cont causes the userspace tool to not print line prefix (e.g.
timestamps) even when following a newline, mis-aligning the output and
making it harder to read, e.g.
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000 ( 128 MB)
vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000 (129022 GB)
.text : 0xffff000008080000 - 0xffff0000088b0000 ( 8384 KB)
.rodata : 0xffff0000088b0000 - 0xffff000008c50000 ( 3712 KB)
.init : 0xffff000008c50000 - 0xffff000008d50000 ( 1024 KB)
.data : 0xffff000008d50000 - 0xffff000008e25200 ( 853 KB)
.bss : 0xffff000008e25200 - 0xffff000008e6bec0 ( 284 KB)
fixed : 0xffff7dfffe7fd000 - 0xffff7dfffec00000 ( 4108 KB)
PCI I/O : 0xffff7dfffee00000 - 0xffff7dffffe00000 ( 16 MB)
vmemmap : 0xffff7e0000000000 - 0xffff800000000000 ( 2048 GB maximum)
0xffff7e0000000000 - 0xffff7e0026000000 ( 608 MB actual)
memory : 0xffff800000000000 - 0xffff800980000000 ( 38912 MB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
Fix this by using pr_notice consistently for all lines, which both the
kernel and userspace are happy with.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-20 11:24:53 +00:00
|
|
|
pr_notice(" .text : 0x%p" " - 0x%p" " (%6ld KB)\n",
|
arm64: mm: fix location of _etext
As Kees Cook notes in the ARM counterpart of this patch [0]:
The _etext position is defined to be the end of the kernel text code,
and should not include any part of the data segments. This interferes
with things that might check memory ranges and expect executable code
up to _etext.
In particular, Kees is referring to the HARDENED_USERCOPY patch set [1],
which rejects attempts to call copy_to_user() on kernel ranges containing
executable code, but does allow access to the .rodata segment. Regardless
of whether one may or may not agree with the distinction, it makes sense
for _etext to have the same meaning across architectures.
So let's put _etext where it belongs, between .text and .rodata, and fix
up existing references to use __init_begin instead, which unlike _end_rodata
includes the exception and notes sections as well.
The _etext references in kaslr.c are left untouched, since its references
to [_stext, _etext) are meant to capture potential jump instruction targets,
and so disregarding .rodata is actually an improvement here.
[0] http://article.gmane.org/gmane.linux.kernel/2245084
[1] http://thread.gmane.org/gmane.linux.kernel.hardened.devel/2502
Reported-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2016-06-23 13:53:17 +00:00
|
|
|
MLK_ROUNDUP(_text, _etext));
|
arm64: remove pr_cont abuse from mem_init
All the lines printed by mem_init are independent, with each ending with
a newline. While they logically form a large block, none are actually
continuations of previous lines.
The kernel-side printk code and the userspace demsg tool differ in their
handling of KERN_CONT following a newline, and while this isn't always a
problem kernel-side, it does cause difficulty for userspace. Using
pr_cont causes the userspace tool to not print line prefix (e.g.
timestamps) even when following a newline, mis-aligning the output and
making it harder to read, e.g.
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000 ( 128 MB)
vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000 (129022 GB)
.text : 0xffff000008080000 - 0xffff0000088b0000 ( 8384 KB)
.rodata : 0xffff0000088b0000 - 0xffff000008c50000 ( 3712 KB)
.init : 0xffff000008c50000 - 0xffff000008d50000 ( 1024 KB)
.data : 0xffff000008d50000 - 0xffff000008e25200 ( 853 KB)
.bss : 0xffff000008e25200 - 0xffff000008e6bec0 ( 284 KB)
fixed : 0xffff7dfffe7fd000 - 0xffff7dfffec00000 ( 4108 KB)
PCI I/O : 0xffff7dfffee00000 - 0xffff7dffffe00000 ( 16 MB)
vmemmap : 0xffff7e0000000000 - 0xffff800000000000 ( 2048 GB maximum)
0xffff7e0000000000 - 0xffff7e0026000000 ( 608 MB actual)
memory : 0xffff800000000000 - 0xffff800980000000 ( 38912 MB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
Fix this by using pr_notice consistently for all lines, which both the
kernel and userspace are happy with.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-20 11:24:53 +00:00
|
|
|
pr_notice(" .rodata : 0x%p" " - 0x%p" " (%6ld KB)\n",
|
arm64: mm: fix location of _etext
As Kees Cook notes in the ARM counterpart of this patch [0]:
The _etext position is defined to be the end of the kernel text code,
and should not include any part of the data segments. This interferes
with things that might check memory ranges and expect executable code
up to _etext.
In particular, Kees is referring to the HARDENED_USERCOPY patch set [1],
which rejects attempts to call copy_to_user() on kernel ranges containing
executable code, but does allow access to the .rodata segment. Regardless
of whether one may or may not agree with the distinction, it makes sense
for _etext to have the same meaning across architectures.
So let's put _etext where it belongs, between .text and .rodata, and fix
up existing references to use __init_begin instead, which unlike _end_rodata
includes the exception and notes sections as well.
The _etext references in kaslr.c are left untouched, since its references
to [_stext, _etext) are meant to capture potential jump instruction targets,
and so disregarding .rodata is actually an improvement here.
[0] http://article.gmane.org/gmane.linux.kernel/2245084
[1] http://thread.gmane.org/gmane.linux.kernel.hardened.devel/2502
Reported-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2016-06-23 13:53:17 +00:00
|
|
|
MLK_ROUNDUP(__start_rodata, __init_begin));
|
arm64: remove pr_cont abuse from mem_init
All the lines printed by mem_init are independent, with each ending with
a newline. While they logically form a large block, none are actually
continuations of previous lines.
The kernel-side printk code and the userspace demsg tool differ in their
handling of KERN_CONT following a newline, and while this isn't always a
problem kernel-side, it does cause difficulty for userspace. Using
pr_cont causes the userspace tool to not print line prefix (e.g.
timestamps) even when following a newline, mis-aligning the output and
making it harder to read, e.g.
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000 ( 128 MB)
vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000 (129022 GB)
.text : 0xffff000008080000 - 0xffff0000088b0000 ( 8384 KB)
.rodata : 0xffff0000088b0000 - 0xffff000008c50000 ( 3712 KB)
.init : 0xffff000008c50000 - 0xffff000008d50000 ( 1024 KB)
.data : 0xffff000008d50000 - 0xffff000008e25200 ( 853 KB)
.bss : 0xffff000008e25200 - 0xffff000008e6bec0 ( 284 KB)
fixed : 0xffff7dfffe7fd000 - 0xffff7dfffec00000 ( 4108 KB)
PCI I/O : 0xffff7dfffee00000 - 0xffff7dffffe00000 ( 16 MB)
vmemmap : 0xffff7e0000000000 - 0xffff800000000000 ( 2048 GB maximum)
0xffff7e0000000000 - 0xffff7e0026000000 ( 608 MB actual)
memory : 0xffff800000000000 - 0xffff800980000000 ( 38912 MB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
Fix this by using pr_notice consistently for all lines, which both the
kernel and userspace are happy with.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-20 11:24:53 +00:00
|
|
|
pr_notice(" .init : 0x%p" " - 0x%p" " (%6ld KB)\n",
|
2016-04-18 03:09:46 +00:00
|
|
|
MLK_ROUNDUP(__init_begin, __init_end));
|
arm64: remove pr_cont abuse from mem_init
All the lines printed by mem_init are independent, with each ending with
a newline. While they logically form a large block, none are actually
continuations of previous lines.
The kernel-side printk code and the userspace demsg tool differ in their
handling of KERN_CONT following a newline, and while this isn't always a
problem kernel-side, it does cause difficulty for userspace. Using
pr_cont causes the userspace tool to not print line prefix (e.g.
timestamps) even when following a newline, mis-aligning the output and
making it harder to read, e.g.
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000 ( 128 MB)
vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000 (129022 GB)
.text : 0xffff000008080000 - 0xffff0000088b0000 ( 8384 KB)
.rodata : 0xffff0000088b0000 - 0xffff000008c50000 ( 3712 KB)
.init : 0xffff000008c50000 - 0xffff000008d50000 ( 1024 KB)
.data : 0xffff000008d50000 - 0xffff000008e25200 ( 853 KB)
.bss : 0xffff000008e25200 - 0xffff000008e6bec0 ( 284 KB)
fixed : 0xffff7dfffe7fd000 - 0xffff7dfffec00000 ( 4108 KB)
PCI I/O : 0xffff7dfffee00000 - 0xffff7dffffe00000 ( 16 MB)
vmemmap : 0xffff7e0000000000 - 0xffff800000000000 ( 2048 GB maximum)
0xffff7e0000000000 - 0xffff7e0026000000 ( 608 MB actual)
memory : 0xffff800000000000 - 0xffff800980000000 ( 38912 MB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
Fix this by using pr_notice consistently for all lines, which both the
kernel and userspace are happy with.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-20 11:24:53 +00:00
|
|
|
pr_notice(" .data : 0x%p" " - 0x%p" " (%6ld KB)\n",
|
2016-03-11 17:39:25 +00:00
|
|
|
MLK_ROUNDUP(_sdata, _edata));
|
arm64: remove pr_cont abuse from mem_init
All the lines printed by mem_init are independent, with each ending with
a newline. While they logically form a large block, none are actually
continuations of previous lines.
The kernel-side printk code and the userspace demsg tool differ in their
handling of KERN_CONT following a newline, and while this isn't always a
problem kernel-side, it does cause difficulty for userspace. Using
pr_cont causes the userspace tool to not print line prefix (e.g.
timestamps) even when following a newline, mis-aligning the output and
making it harder to read, e.g.
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000 ( 128 MB)
vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000 (129022 GB)
.text : 0xffff000008080000 - 0xffff0000088b0000 ( 8384 KB)
.rodata : 0xffff0000088b0000 - 0xffff000008c50000 ( 3712 KB)
.init : 0xffff000008c50000 - 0xffff000008d50000 ( 1024 KB)
.data : 0xffff000008d50000 - 0xffff000008e25200 ( 853 KB)
.bss : 0xffff000008e25200 - 0xffff000008e6bec0 ( 284 KB)
fixed : 0xffff7dfffe7fd000 - 0xffff7dfffec00000 ( 4108 KB)
PCI I/O : 0xffff7dfffee00000 - 0xffff7dffffe00000 ( 16 MB)
vmemmap : 0xffff7e0000000000 - 0xffff800000000000 ( 2048 GB maximum)
0xffff7e0000000000 - 0xffff7e0026000000 ( 608 MB actual)
memory : 0xffff800000000000 - 0xffff800980000000 ( 38912 MB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
Fix this by using pr_notice consistently for all lines, which both the
kernel and userspace are happy with.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-20 11:24:53 +00:00
|
|
|
pr_notice(" .bss : 0x%p" " - 0x%p" " (%6ld KB)\n",
|
2016-04-18 03:09:47 +00:00
|
|
|
MLK_ROUNDUP(__bss_start, __bss_stop));
|
arm64: remove pr_cont abuse from mem_init
All the lines printed by mem_init are independent, with each ending with
a newline. While they logically form a large block, none are actually
continuations of previous lines.
The kernel-side printk code and the userspace demsg tool differ in their
handling of KERN_CONT following a newline, and while this isn't always a
problem kernel-side, it does cause difficulty for userspace. Using
pr_cont causes the userspace tool to not print line prefix (e.g.
timestamps) even when following a newline, mis-aligning the output and
making it harder to read, e.g.
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000 ( 128 MB)
vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000 (129022 GB)
.text : 0xffff000008080000 - 0xffff0000088b0000 ( 8384 KB)
.rodata : 0xffff0000088b0000 - 0xffff000008c50000 ( 3712 KB)
.init : 0xffff000008c50000 - 0xffff000008d50000 ( 1024 KB)
.data : 0xffff000008d50000 - 0xffff000008e25200 ( 853 KB)
.bss : 0xffff000008e25200 - 0xffff000008e6bec0 ( 284 KB)
fixed : 0xffff7dfffe7fd000 - 0xffff7dfffec00000 ( 4108 KB)
PCI I/O : 0xffff7dfffee00000 - 0xffff7dffffe00000 ( 16 MB)
vmemmap : 0xffff7e0000000000 - 0xffff800000000000 ( 2048 GB maximum)
0xffff7e0000000000 - 0xffff7e0026000000 ( 608 MB actual)
memory : 0xffff800000000000 - 0xffff800980000000 ( 38912 MB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
Fix this by using pr_notice consistently for all lines, which both the
kernel and userspace are happy with.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-20 11:24:53 +00:00
|
|
|
pr_notice(" fixed : 0x%16lx - 0x%16lx (%6ld KB)\n",
|
2016-03-30 14:46:00 +00:00
|
|
|
MLK(FIXADDR_START, FIXADDR_TOP));
|
arm64: remove pr_cont abuse from mem_init
All the lines printed by mem_init are independent, with each ending with
a newline. While they logically form a large block, none are actually
continuations of previous lines.
The kernel-side printk code and the userspace demsg tool differ in their
handling of KERN_CONT following a newline, and while this isn't always a
problem kernel-side, it does cause difficulty for userspace. Using
pr_cont causes the userspace tool to not print line prefix (e.g.
timestamps) even when following a newline, mis-aligning the output and
making it harder to read, e.g.
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000 ( 128 MB)
vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000 (129022 GB)
.text : 0xffff000008080000 - 0xffff0000088b0000 ( 8384 KB)
.rodata : 0xffff0000088b0000 - 0xffff000008c50000 ( 3712 KB)
.init : 0xffff000008c50000 - 0xffff000008d50000 ( 1024 KB)
.data : 0xffff000008d50000 - 0xffff000008e25200 ( 853 KB)
.bss : 0xffff000008e25200 - 0xffff000008e6bec0 ( 284 KB)
fixed : 0xffff7dfffe7fd000 - 0xffff7dfffec00000 ( 4108 KB)
PCI I/O : 0xffff7dfffee00000 - 0xffff7dffffe00000 ( 16 MB)
vmemmap : 0xffff7e0000000000 - 0xffff800000000000 ( 2048 GB maximum)
0xffff7e0000000000 - 0xffff7e0026000000 ( 608 MB actual)
memory : 0xffff800000000000 - 0xffff800980000000 ( 38912 MB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
Fix this by using pr_notice consistently for all lines, which both the
kernel and userspace are happy with.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-20 11:24:53 +00:00
|
|
|
pr_notice(" PCI I/O : 0x%16lx - 0x%16lx (%6ld MB)\n",
|
2016-03-30 14:46:00 +00:00
|
|
|
MLM(PCI_IO_START, PCI_IO_END));
|
2012-03-05 11:49:27 +00:00
|
|
|
#ifdef CONFIG_SPARSEMEM_VMEMMAP
|
arm64: remove pr_cont abuse from mem_init
All the lines printed by mem_init are independent, with each ending with
a newline. While they logically form a large block, none are actually
continuations of previous lines.
The kernel-side printk code and the userspace demsg tool differ in their
handling of KERN_CONT following a newline, and while this isn't always a
problem kernel-side, it does cause difficulty for userspace. Using
pr_cont causes the userspace tool to not print line prefix (e.g.
timestamps) even when following a newline, mis-aligning the output and
making it harder to read, e.g.
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000 ( 128 MB)
vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000 (129022 GB)
.text : 0xffff000008080000 - 0xffff0000088b0000 ( 8384 KB)
.rodata : 0xffff0000088b0000 - 0xffff000008c50000 ( 3712 KB)
.init : 0xffff000008c50000 - 0xffff000008d50000 ( 1024 KB)
.data : 0xffff000008d50000 - 0xffff000008e25200 ( 853 KB)
.bss : 0xffff000008e25200 - 0xffff000008e6bec0 ( 284 KB)
fixed : 0xffff7dfffe7fd000 - 0xffff7dfffec00000 ( 4108 KB)
PCI I/O : 0xffff7dfffee00000 - 0xffff7dffffe00000 ( 16 MB)
vmemmap : 0xffff7e0000000000 - 0xffff800000000000 ( 2048 GB maximum)
0xffff7e0000000000 - 0xffff7e0026000000 ( 608 MB actual)
memory : 0xffff800000000000 - 0xffff800980000000 ( 38912 MB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
Fix this by using pr_notice consistently for all lines, which both the
kernel and userspace are happy with.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-20 11:24:53 +00:00
|
|
|
pr_notice(" vmemmap : 0x%16lx - 0x%16lx (%6ld GB maximum)\n",
|
2016-04-18 03:09:46 +00:00
|
|
|
MLG(VMEMMAP_START, VMEMMAP_START + VMEMMAP_SIZE));
|
arm64: remove pr_cont abuse from mem_init
All the lines printed by mem_init are independent, with each ending with
a newline. While they logically form a large block, none are actually
continuations of previous lines.
The kernel-side printk code and the userspace demsg tool differ in their
handling of KERN_CONT following a newline, and while this isn't always a
problem kernel-side, it does cause difficulty for userspace. Using
pr_cont causes the userspace tool to not print line prefix (e.g.
timestamps) even when following a newline, mis-aligning the output and
making it harder to read, e.g.
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000 ( 128 MB)
vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000 (129022 GB)
.text : 0xffff000008080000 - 0xffff0000088b0000 ( 8384 KB)
.rodata : 0xffff0000088b0000 - 0xffff000008c50000 ( 3712 KB)
.init : 0xffff000008c50000 - 0xffff000008d50000 ( 1024 KB)
.data : 0xffff000008d50000 - 0xffff000008e25200 ( 853 KB)
.bss : 0xffff000008e25200 - 0xffff000008e6bec0 ( 284 KB)
fixed : 0xffff7dfffe7fd000 - 0xffff7dfffec00000 ( 4108 KB)
PCI I/O : 0xffff7dfffee00000 - 0xffff7dffffe00000 ( 16 MB)
vmemmap : 0xffff7e0000000000 - 0xffff800000000000 ( 2048 GB maximum)
0xffff7e0000000000 - 0xffff7e0026000000 ( 608 MB actual)
memory : 0xffff800000000000 - 0xffff800980000000 ( 38912 MB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
Fix this by using pr_notice consistently for all lines, which both the
kernel and userspace are happy with.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-20 11:24:53 +00:00
|
|
|
pr_notice(" 0x%16lx - 0x%16lx (%6ld MB actual)\n",
|
2016-03-11 17:39:25 +00:00
|
|
|
MLM((unsigned long)phys_to_page(memblock_start_of_DRAM()),
|
|
|
|
(unsigned long)virt_to_page(high_memory)));
|
2012-03-05 11:49:27 +00:00
|
|
|
#endif
|
arm64: remove pr_cont abuse from mem_init
All the lines printed by mem_init are independent, with each ending with
a newline. While they logically form a large block, none are actually
continuations of previous lines.
The kernel-side printk code and the userspace demsg tool differ in their
handling of KERN_CONT following a newline, and while this isn't always a
problem kernel-side, it does cause difficulty for userspace. Using
pr_cont causes the userspace tool to not print line prefix (e.g.
timestamps) even when following a newline, mis-aligning the output and
making it harder to read, e.g.
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000 ( 128 MB)
vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000 (129022 GB)
.text : 0xffff000008080000 - 0xffff0000088b0000 ( 8384 KB)
.rodata : 0xffff0000088b0000 - 0xffff000008c50000 ( 3712 KB)
.init : 0xffff000008c50000 - 0xffff000008d50000 ( 1024 KB)
.data : 0xffff000008d50000 - 0xffff000008e25200 ( 853 KB)
.bss : 0xffff000008e25200 - 0xffff000008e6bec0 ( 284 KB)
fixed : 0xffff7dfffe7fd000 - 0xffff7dfffec00000 ( 4108 KB)
PCI I/O : 0xffff7dfffee00000 - 0xffff7dffffe00000 ( 16 MB)
vmemmap : 0xffff7e0000000000 - 0xffff800000000000 ( 2048 GB maximum)
0xffff7e0000000000 - 0xffff7e0026000000 ( 608 MB actual)
memory : 0xffff800000000000 - 0xffff800980000000 ( 38912 MB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
Fix this by using pr_notice consistently for all lines, which both the
kernel and userspace are happy with.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-20 11:24:53 +00:00
|
|
|
pr_notice(" memory : 0x%16lx - 0x%16lx (%6ld MB)\n",
|
2016-03-11 17:39:25 +00:00
|
|
|
MLM(__phys_to_virt(memblock_start_of_DRAM()),
|
|
|
|
(unsigned long)high_memory));
|
2012-03-05 11:49:27 +00:00
|
|
|
|
|
|
|
#undef MLK
|
|
|
|
#undef MLM
|
|
|
|
#undef MLK_ROUNDUP
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check boundaries twice: Some fundamental inconsistencies can be
|
|
|
|
* detected at build time already.
|
|
|
|
*/
|
|
|
|
#ifdef CONFIG_COMPAT
|
|
|
|
BUILD_BUG_ON(TASK_SIZE_32 > TASK_SIZE_64);
|
|
|
|
#endif
|
|
|
|
|
2016-03-30 14:46:00 +00:00
|
|
|
/*
|
|
|
|
* Make sure we chose the upper bound of sizeof(struct page)
|
|
|
|
* correctly.
|
|
|
|
*/
|
|
|
|
BUILD_BUG_ON(sizeof(struct page) > (1 << STRUCT_PAGE_MAX_SHIFT));
|
|
|
|
|
2013-07-03 22:03:49 +00:00
|
|
|
if (PAGE_SIZE >= 16384 && get_num_physpages() <= 128) {
|
2012-03-05 11:49:27 +00:00
|
|
|
extern int sysctl_overcommit_memory;
|
|
|
|
/*
|
|
|
|
* On a machine this small we won't get anywhere without
|
|
|
|
* overcommit, so turn it on by default.
|
|
|
|
*/
|
|
|
|
sysctl_overcommit_memory = OVERCOMMIT_ALWAYS;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void free_initmem(void)
|
|
|
|
{
|
2017-01-10 21:35:49 +00:00
|
|
|
free_reserved_area(lm_alias(__init_begin),
|
|
|
|
lm_alias(__init_end),
|
2016-03-30 14:45:57 +00:00
|
|
|
0, "unused kernel");
|
2016-09-05 11:30:22 +00:00
|
|
|
/*
|
|
|
|
* Unmap the __init region but leave the VM area in place. This
|
|
|
|
* prevents the region from being reused for kernel modules, which
|
|
|
|
* is not supported by kallsyms.
|
|
|
|
*/
|
|
|
|
unmap_kernel_range((u64)__init_begin, (u64)(__init_end - __init_begin));
|
2012-03-05 11:49:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_BLK_DEV_INITRD
|
|
|
|
|
2015-07-27 02:32:53 +00:00
|
|
|
static int keep_initrd __initdata;
|
2012-03-05 11:49:27 +00:00
|
|
|
|
2015-07-27 02:32:53 +00:00
|
|
|
void __init free_initrd_mem(unsigned long start, unsigned long end)
|
2012-03-05 11:49:27 +00:00
|
|
|
{
|
2015-01-16 13:56:38 +00:00
|
|
|
if (!keep_initrd)
|
2013-07-03 22:02:54 +00:00
|
|
|
free_reserved_area((void *)start, (void *)end, 0, "initrd");
|
2012-03-05 11:49:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int __init keepinitrd_setup(char *__unused)
|
|
|
|
{
|
|
|
|
keep_initrd = 1;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
__setup("keepinitrd", keepinitrd_setup);
|
|
|
|
#endif
|
2016-02-16 12:52:42 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Dump out memory limit information on panic.
|
|
|
|
*/
|
|
|
|
static int dump_mem_limit(struct notifier_block *self, unsigned long v, void *p)
|
|
|
|
{
|
|
|
|
if (memory_limit != (phys_addr_t)ULLONG_MAX) {
|
|
|
|
pr_emerg("Memory Limit: %llu MB\n", memory_limit >> 20);
|
|
|
|
} else {
|
|
|
|
pr_emerg("Memory Limit: none\n");
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct notifier_block mem_limit_notifier = {
|
|
|
|
.notifier_call = dump_mem_limit,
|
|
|
|
};
|
|
|
|
|
|
|
|
static int __init register_mem_limit_dumper(void)
|
|
|
|
{
|
|
|
|
atomic_notifier_chain_register(&panic_notifier_list,
|
|
|
|
&mem_limit_notifier);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
__initcall(register_mem_limit_dumper);
|