linux-stable.git/arch/mips/kernel/setup.c, branch v4.19.232

MIPS: Make sparse_init() using top-down allocation

2020-06-22T07:05:13+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: avoid explicit UB in assignment of mips_io_port_base

2020-01-27T13:51:07+00:00

[ Upstream commit 12051b318bc3ce5b42d6d786191008284b067d83 ]

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
Signed-off-by: Sasha Levin

MIPS: Fix CONFIG_CMDLINE handling

2018-09-28T19:09:04+00:00

Commit 8ce355cf2e38 ("MIPS: Setup boot_command_line before
plat_mem_setup") fixed a problem for systems which have
CONFIG_CMDLINE_BOOL=y & use a DT with a chosen node that has either no
bootargs property or an empty one. In this configuration
early_init_dt_scan_chosen() copies CONFIG_CMDLINE into
boot_command_line, but the MIPS code doesn't know this so it appends
CONFIG_CMDLINE (via builtin_cmdline) to boot_command_line again. The
result is that boot_command_line contains the arguments from
CONFIG_CMDLINE twice.

That commit took the approach of simply setting up boot_command_line
from the MIPS code before early_init_dt_scan_chosen() runs, causing it
not to copy CONFIG_CMDLINE to boot_command_line if a chosen node with no
bootargs property is found.

Unfortunately this is problematic for systems which do have a non-empty
bootargs property & CONFIG_CMDLINE_BOOL=y. There
early_init_dt_scan_chosen() will overwrite boot_command_line with the
arguments from DT, which means we lose those from CONFIG_CMDLINE
entirely. This breaks CONFIG_MIPS_CMDLINE_DTB_EXTEND. If we have
CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER or
CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND selected and the DT has a bootargs
property which we should ignore, it will instead be honoured breaking
those configurations too.

Fix this by reverting commit 8ce355cf2e38 ("MIPS: Setup
boot_command_line before plat_mem_setup") to restore the former
behaviour, and fixing the CONFIG_CMDLINE duplication issue by
initializing boot_command_line to a non-empty string that
early_init_dt_scan_chosen() will not overwrite with CONFIG_CMDLINE.

This is a little ugly, but cleanup in this area is on its way. In the
meantime this is at least easy to backport & contains the ugliness
within arch/mips/.

Signed-off-by: Paul Burton 
Fixes: 8ce355cf2e38 ("MIPS: Setup boot_command_line before plat_mem_setup")
References: https://patchwork.linux-mips.org/patch/18804/
Patchwork: https://patchwork.linux-mips.org/patch/20813/
Cc: Frank Rowand 
Cc: Jaedon Shin 
Cc: Mathieu Malaterre 
Cc: Rob Herring 
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org # v4.16+

MIPS: Allow auto-dection of ARCH_PFN_OFFSET & PHYS_OFFSET

2018-07-30T17:27:32+00:00

On systems where physical memory begins at a non-zero address, defining
PHYS_OFFSET (which influences ARCH_PFN_OFFSET) can save us time & memory
by avoiding book-keeping for pages from address zero to the start of
memory.

Some MIPS platforms already make use of this, but with the definition of
PHYS_OFFSET being compile-time constant it hasn't been possible to
enable this optimization for a kernel which may run on systems with
varying physical memory base addresses.

Introduce a new Kconfig option CONFIG_MIPS_AUTO_PFN_OFFSET which, when
enabled, makes ARCH_PFN_OFFSET a variable & detects it from the boot
memory map (which for example may have been populated from DT). The
relationship with PHYS_OFFSET is reversed, with PHYS_OFFSET now being
based on ARCH_PFN_OFFSET. This is because ARCH_PFN_OFFSET is used far
more often, so avoiding the need for runtime calculation gives us a
smaller impact on kernel text size (0.1% rather than 0.15% for
64r6el_defconfig).

Signed-off-by: Paul Burton 
Suggested-by: Vladimir Kondratiev 
Patchwork: https://patchwork.linux-mips.org/patch/20048/
Cc: James Hogan 
Cc: Ralf Baechle 
Cc: linux-mips@linux-mips.org

MIPS: move coherentio setup to setup.c

2018-06-24T16:26:04+00:00

We want to be able to use it even when not building dma-default.c
in the near future.

Signed-off-by: Christoph Hellwig 
Patchwork: https://patchwork.linux-mips.org/patch/19543/
Signed-off-by: Paul Burton 
Cc: Florian Fainelli 
Cc: David Daney 
Cc: Kevin Cernekee 
Cc: Jiaxun Yang 
Cc: Tom Bogendoerfer 
Cc: Huacai Chen 
Cc: iommu@lists.linux-foundation.org
Cc: linux-mips@linux-mips.org

treewide: use PHYS_ADDR_MAX to avoid type casting ULLONG_MAX

2018-06-14T22:55:25+00:00

With PHYS_ADDR_MAX there is now a type safe variant for all bits set.
Make use of it.

Patch created using a semantic patch as follows:

// 
@@
typedef phys_addr_t;
@@
-(phys_addr_t)ULLONG_MAX
+PHYS_ADDR_MAX
// 

Link: http://lkml.kernel.org/r/20180419214204.19322-1-stefan@agner.ch
Signed-off-by: Stefan Agner 
Reviewed-by: Andrew Morton 
Acked-by: Ard Biesheuvel 
Acked-by: Catalin Marinas 	[arm64]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

MIPS: Remove a warning when PHYS_OFFSET is 0x0

2018-02-19T10:55:38+00:00

Rewrite the comparison in `else if` statement, case where `min_low_pfn >
ARCH_PFN_OFFSET` has already been checked in the first `if` statement:

  if (min_low_pfn > ARCH_PFN_OFFSET) {

Fix non-fatal warning during compilation using W=1:

arch/mips/kernel/setup.c: In function ‘bootmem_init’:
arch/mips/kernel/setup.c:461:25: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
  } else if (min_low_pfn < ARCH_PFN_OFFSET) {
                         ^

Signed-off-by: Mathieu Malaterre 
Reviewed-by: James Hogan 
Cc: Ralf Baechle 
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/18176/
Signed-off-by: James Hogan

MIPS: Make declaration for function `memory_region_available` static

2018-02-19T10:55:38+00:00

Fix non-fatal warning during compilation using W=1:

arch/mips/kernel/setup.c:158:13: warning: no previous prototype for ‘memory_region_available’ [-Wmissing-prototypes]
 bool __init memory_region_available(phys_addr_t start, phys_addr_t size)
             ^~~~~~~~~~~~~~~~~~~~~~~

Signed-off-by: Mathieu Malaterre 
Cc: Ralf Baechle 
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/18175/
[jhogan@kernel.org: tweak whitespace]
Signed-off-by: James Hogan

MIPS: Fix incorrect mem=X@Y handling

2018-02-13T13:14:41+00:00

Commit 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing") added a
fix to ensure that the memory range between PHYS_OFFSET and low memory
address specified by mem= cmdline argument is not later processed by
free_all_bootmem.  This change was incorrect for systems where the
commandline specifies more than 1 mem argument, as it will cause all
memory between PHYS_OFFSET and each of the memory offsets to be marked
as reserved, which results in parts of the RAM marked as reserved
(Creator CI20's u-boot has a default commandline argument 'mem=256M@0x0
mem=768M@0x30000000').

Change the behaviour to ensure that only the range between PHYS_OFFSET
and the lowest start address of the memories is marked as protected.

This change also ensures that the range is marked protected even if it's
only defined through the devicetree and not only via commandline
arguments.

Reported-by: Mathieu Malaterre 
Signed-off-by: Marcin Nowakowski 
Fixes: 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing")
Cc: Ralf Baechle 
Cc: linux-mips@linux-mips.org
Cc:  # v4.11+
Tested-by: Mathieu Malaterre 
Patchwork: https://patchwork.linux-mips.org/patch/18562/
Signed-off-by: James Hogan

MIPS: Setup boot_command_line before plat_mem_setup

2018-01-18T22:06:07+00:00

Platforms using DT will typically call __dt_setup_arch from
plat_mem_setup. This in turn calls early_init_dt_scan. When
CONFIG_CMDLINE is set, this leads to its value being copied into
boot_command_line by early_init_dt_scan_chosen. If this happens before
the code setting up boot_command_line in arch_mem_init runs, that code
will go on to append CONFIG_CMDLINE (via builtin_cmdline) to
boot_command_line again, duplicating it. For some command line
parameters (eg. earlycon) this can be a problem. Set up
boot_command_line before early_init_dt_scan_chosen gets called such that
it will not write CONFIG_CMDLINE in this scenario & the arguments aren't
duplicated.

Signed-off-by: Paul Burton 
Acked-by: Mathieu Malaterre 
Cc: Ralf Baechle 
Cc: Maarten ter Huurne 
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/18483/
Signed-off-by: James Hogan