linux-stable.git/arch/mips/kernel/setup.c, branch v5.4.76

MIPS: Fix unable to reserve memory for Crash kernel

2020-08-26T08:40:55+00:00

[ Upstream commit b1ce9716f3b5ed3b49badf1f003b9e34b7ead0f9 ]

Use 0 as the align parameter in memblock_find_in_range() is
incorrect when we reserve memory for Crash kernel.

The environment as follows:
[    0.000000] MIPS: machine is loongson,loongson64c-4core-rs780e
...
[    1.951016]     crashkernel=64M@128M

The warning as follows:
[    0.000000] Invalid memory region reserved for crash kernel

And the iomem as follows:
00200000-0effffff : System RAM
  04000000-0484009f : Kernel code
  048400a0-04ad7fff : Kernel data
  04b40000-05c4c6bf : Kernel bss
1a000000-1bffffff : pci@1a000000
...

The align parameter may be finally used by round_down() or round_up().
Like the following call tree:

mips-next: mm/memblock.c

memblock_find_in_range
└── memblock_find_in_range_node
    ├── __memblock_find_range_bottom_up
    │   └── round_up
    └── __memblock_find_range_top_down
        └── round_down
\#define round_up(x, y) ((((x)-1) | __round_mask(x, y))+1)
\#define round_down(x, y) ((x) & ~__round_mask(x, y))
\#define __round_mask(x, y) ((__typeof__(x))((y)-1))

The round_down(or round_up)'s second parameter must be a power of 2.
If the second parameter is 0, it both will return 0.

Use 1 as the parameter to fix the bug and the iomem as follows:
00200000-0effffff : System RAM
  04000000-0484009f : Kernel code
  048400a0-04ad7fff : Kernel data
  04b40000-05c4c6bf : Kernel bss
  08000000-0bffffff : Crash kernel
1a000000-1bffffff : pci@1a000000
...

Signed-off-by: Jinyang He 
Reviewed-by: Jiaxun Yang 
Signed-off-by: Thomas Bogendoerfer 
Signed-off-by: Sasha Levin

MIPS: Make sparse_init() using top-down allocation

2020-06-22T07:30:59+00:00

[ Upstream commit 269b3a9ac538c4ae87f84be640b9fa89914a2489 ]

In the current code, if CONFIG_SWIOTLB is set, when failed to get IO TLB
memory from the low pages by plat_swiotlb_setup(), it may lead to the boot
process failed with kernel panic.

(1) On the Loongson and SiByte platform
arch/mips/loongson64/dma.c
arch/mips/sibyte/common/dma.c
void __init plat_swiotlb_setup(void)
{
	swiotlb_init(1);
}

kernel/dma/swiotlb.c
void  __init
swiotlb_init(int verbose)
{
...
	vstart = memblock_alloc_low(PAGE_ALIGN(bytes), PAGE_SIZE);
	if (vstart && !swiotlb_init_with_tbl(vstart, io_tlb_nslabs, verbose))
		return;
...
	pr_warn("Cannot allocate buffer");
	no_iotlb_memory = true;
}

phys_addr_t swiotlb_tbl_map_single()
{
...
	if (no_iotlb_memory)
		panic("Can not allocate SWIOTLB buffer earlier ...");
...
}

(2) On the Cavium OCTEON platform
arch/mips/cavium-octeon/dma-octeon.c
void __init plat_swiotlb_setup(void)
{
...
	octeon_swiotlb = memblock_alloc_low(swiotlbsize, PAGE_SIZE);
	if (!octeon_swiotlb)
		panic("%s: Failed to allocate %zu bytes align=%lx\n",
		      __func__, swiotlbsize, PAGE_SIZE);
...
}

Because IO_TLB_DEFAULT_SIZE is 64M, if the rest size of low memory is less
than 64M when call plat_swiotlb_setup(), we can easily reproduce the panic
case.

In order to reduce the possibility of kernel panic when failed to get IO
TLB memory under CONFIG_SWIOTLB, it is better to allocate low memory as
small as possible before plat_swiotlb_setup(), so make sparse_init() using
top-down allocation.

Reported-by: Juxin Gao 
Co-developed-by: Juxin Gao 
Signed-off-by: Juxin Gao 
Signed-off-by: Tiezhu Yang 
Signed-off-by: Thomas Bogendoerfer 
Signed-off-by: Sasha Levin

MIPS: init: Prevent adding memory before PHYS_OFFSET

2019-10-02T21:11:30+00:00

On some SGI machines (IP28 and IP30) a small region of memory is mirrored
to pyhsical address 0 for exception vectors while rest of the memory
is reachable at a higher physical address. ARC PROM marks this
region as reserved, but with commit a94e4f24ec83 ("MIPS: init: Drop
boot_mem_map") this chunk is used, when searching for start of ram,
which breaks at least IP28 and IP30 machines. To fix this
add_region_memory() checks for start address < PHYS_OFFSET and ignores
these chunks.

Fixes: a94e4f24ec83 ("MIPS: init: Drop boot_mem_map")
Signed-off-by: Thomas Bogendoerfer 
Signed-off-by: Paul Burton 
Cc: Ralf Baechle 
Cc: James Hogan 
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

MIPS: init: Fix reservation of memory between PHYS_OFFSET and mem start

2019-10-02T21:10:16+00:00

Fix calculation of the size for reserving memory between PHYS_OFFSET
and real memory start.

Fixes: a94e4f24ec83 ("MIPS: init: Drop boot_mem_map")
Signed-off-by: Thomas Bogendoerfer 
Signed-off-by: Paul Burton 
Cc: Ralf Baechle 
Cc: James Hogan 
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

mips: avoid explicit UB in assignment of mips_io_port_base

2019-08-24T14:10:58+00:00

The code in question is modifying a variable declared const through
pointer manipulation.  Such code is explicitly undefined behavior, and
is the lone issue preventing malta_defconfig from booting when built
with Clang:

If an attempt is made to modify an object defined with a const-qualified
type through use of an lvalue with non-const-qualified type, the
behavior is undefined.

LLVM is removing such assignments. A simple fix is to not declare
variables const that you plan on modifying.  Limiting the scope would be
a better method of preventing unwanted writes to such a variable.

Further, the code in question mentions "compiler bugs" without any links
to bug reports, so it is difficult to know if the issue is resolved in
GCC. The patch was authored in 2006, which would have been GCC 4.0.3 or
4.1.1. The minimal supported version of GCC in the Linux kernel is
currently 4.6.

For what its worth, there was UB before the commit in question, it just
added a barrier and got lucky IRT codegen. I don't think there's any
actual compiler bugs related, just runtime bugs due to UB.

Link: https://github.com/ClangBuiltLinux/linux/issues/610
Fixes: 966f4406d903 ("[MIPS] Work around bad code generation for .")
Reported-by: Nathan Chancellor 
Debugged-by: Nathan Chancellor 
Suggested-by: Eli Friedman 
Signed-off-by: Nick Desaulniers 
Reviewed-by: Nathan Chancellor 
Tested-by: Nathan Chancellor 
Signed-off-by: Paul Burton 
Cc: ralf@linux-mips.org
Cc: jhogan@kernel.org
Cc: Maciej W. Rozycki 
Cc: Hassan Naveed 
Cc: Stephen Kitt 
Cc: Serge Semin 
Cc: Mike Rapoport 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: clang-built-linux@googlegroups.com

MIPS: Fix build with CONFIG_PROC_VMCORE=y

2019-08-23T17:02:49+00:00

Commit a94e4f24ec83 ("MIPS: init: Drop boot_mem_map") introduced a
reference to a non-existant "end" field in struct memblock_region.
Replace it with a sum of the base & size fields to fix builds with
CONFIG_PROC_VMCORE=y.

Reported-by: kbuild test robot 
Signed-off-by: Paul Burton

MIPS: init: Drop boot_mem_map

2019-08-23T14:42:40+00:00

boot_mem_map was introduced very early and cannot handle memory maps
with nid. Nowadays, memblock can exactly replace boot_mem_map.

Detect pfn info and setup resources with memblock maps.

Signed-off-by: Jiaxun Yang 
[paul.burton@mips.com: Fix size calculation in check_kernel_sections_mem]
Signed-off-by: Paul Burton 
Cc: linux-mips@vger.kernel.org
Cc: yasha.che3@gmail.com
Cc: aurelien@aurel32.net
Cc: sfr@canb.auug.org.au
Cc: fancer.lancer@gmail.com
Cc: matt.redfearn@mips.com
Cc: chenhc@lemote.com

mips: Manually call fdt_init_reserved_mem() method

2019-05-06T03:12:20+00:00

Since memblock-patchset was introduced the reserved-memory nodes are
supported being declared in dt-files. So these nodes are actually parsed
during the arch setup procedure when the early_init_fdt_scan_reserved_mem()
method is called. But due to the arch-specific boot mem_map container
utilization we need to manually call the fdt_init_reserved_mem() method
after all the available and reserved memory has been moved to memblock.
The first function call performed before bootmem_init() by the
early_init_fdt_scan_reserved_mem() routine fails due to the lack of any
memblock memory regions to allocate from at that stage.

Signed-off-by: Serge Semin 
Signed-off-by: Paul Burton 
Cc: Ralf Baechle 
Cc: James Hogan 
Cc: Mike Rapoport 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Greg Kroah-Hartman 
Cc: Thomas Bogendoerfer 
Cc: Huacai Chen 
Cc: Stefan Agner 
Cc: Stephen Rothwell 
Cc: Alexandre Belloni 
Cc: Juergen Gross 
Cc: Serge Semin 
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

mips: Perform early low memory test

2019-05-03T22:26:10+00:00

memblock subsystem provides a method to optionally test the passed
memory region in case if it was requested via special kernel boot
argument. Lets add the function at the bottom of the arch_mem_init()
method. Testing at this point in the boot sequence should be safe since all
critical areas are now reserved and a minimum of allocations have been
done.

Reviewed-by: Matt Redfearn 
Signed-off-by: Serge Semin 
Signed-off-by: Paul Burton 
Cc: Ralf Baechle 
Cc: James Hogan 
Cc: Mike Rapoport 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Greg Kroah-Hartman 
Cc: Thomas Bogendoerfer 
Cc: Huacai Chen 
Cc: Stefan Agner 
Cc: Stephen Rothwell 
Cc: Alexandre Belloni 
Cc: Juergen Gross 
Cc: Serge Semin 
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

mips: Dump memblock regions for debugging

2019-05-03T22:24:12+00:00

It is useful to have the whole memblock memory space printed to console
when basic memlock initializations are done. It can be performed by
ready-to-use method memblock_dump_all(), which prints the available
and reserved memory spaces if memblock=debug kernel parameter is
specified. Lets call it at the very end of arch_mem_init() function,
when all memblock memory and reserved regions are defined, but before
any serious allocation is performed.

Signed-off-by: Serge Semin 
Signed-off-by: Paul Burton 
Cc: Ralf Baechle 
Cc: James Hogan 
Cc: Mike Rapoport 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Greg Kroah-Hartman 
Cc: Thomas Bogendoerfer 
Cc: Huacai Chen 
Cc: Stefan Agner 
Cc: Stephen Rothwell 
Cc: Alexandre Belloni 
Cc: Juergen Gross 
Cc: Serge Semin 
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org