linux-stable.git/arch/mips, branch v5.4.136

Revert "MIPS: add PMD table accounting into MIPS'pmd_alloc_one"

2021-07-28T11:30:58+00:00

This reverts commit 002d8b395fa1c0679fc3c3e68873de6c1cc300a2 which is
commit ed914d48b6a1040d1039d371b56273d422c0081e upstream.

Commit b2b29d6d011944 (mm: account PMD tables like PTE tables) is
introduced between v5.9 and v5.10, so this fix (commit 002d8b395fa1)
should NOT apply to any pre-5.10 branch.

Signed-off-by: Huang Pei 
Signed-off-by: Greg Kroah-Hartman

MIPS: vdso: Invalid GIC access through VDSO

2021-07-20T14:10:53+00:00

[ Upstream commit 47ce8527fbba145a7723685bc9a27d9855e06491 ]

Accessing raw timers (currently only CLOCK_MONOTONIC_RAW) through VDSO
doesn't return the correct time when using the GIC as clock source.
The address of the GIC mapped page is in this case not calculated
correctly. The GIC mapped page is calculated from the VDSO data by
subtracting PAGE_SIZE:

  void *get_gic(const struct vdso_data *data) {
    return (void __iomem *)data - PAGE_SIZE;
  }

However, the data pointer is not page aligned for raw clock sources.
This is because the VDSO data for raw clock sources (CS_RAW = 1) is
stored after the VDSO data for coarse clock sources (CS_HRES_COARSE = 0).
Therefore, only the VDSO data for CS_HRES_COARSE is page aligned:

  +--------------------+
  |                    |
  | vd[CS_RAW]         | ---+
  | vd[CS_HRES_COARSE] |    |
  +--------------------+    | -PAGE_SIZE
  |                    |    |
  |  GIC mapped page   | <--+
  |                    |
  +--------------------+

When __arch_get_hw_counter() is called with &vd[CS_RAW], get_gic returns
the wrong address (somewhere inside the GIC mapped page). The GIC counter
values are not returned which results in an invalid time.

Fixes: a7f4df4e21dd ("MIPS: VDSO: Add implementations of gettimeofday() and clock_gettime()")
Signed-off-by: Martin Fäcknitz 
Signed-off-by: Thomas Bogendoerfer 
Signed-off-by: Sasha Levin

mips: disable branch profiling in boot/decompress.o

2021-07-20T14:10:53+00:00

[ Upstream commit 97e488073cfca0eea84450169ca4cbfcc64e33e3 ]

Use DISABLE_BRANCH_PROFILING for arch/mips/boot/compressed/decompress.o
to prevent linkage errors.

mips64-linux-ld: arch/mips/boot/compressed/decompress.o: in function `LZ4_decompress_fast_extDict':
decompress.c:(.text+0x8c): undefined reference to `ftrace_likely_update'
mips64-linux-ld: decompress.c:(.text+0xf4): undefined reference to `ftrace_likely_update'
mips64-linux-ld: decompress.c:(.text+0x200): undefined reference to `ftrace_likely_update'
mips64-linux-ld: decompress.c:(.text+0x230): undefined reference to `ftrace_likely_update'
mips64-linux-ld: decompress.c:(.text+0x320): undefined reference to `ftrace_likely_update'
mips64-linux-ld: arch/mips/boot/compressed/decompress.o:decompress.c:(.text+0x3f4): more undefined references to `ftrace_likely_update' follow

Fixes: e76e1fdfa8f8 ("lib: add support for LZ4-compressed kernel")
Reported-by: kernel test robot 
Signed-off-by: Randy Dunlap 
Cc: Thomas Bogendoerfer 
Cc: linux-mips@vger.kernel.org
Cc: Kyungsik Lee 
Signed-off-by: Thomas Bogendoerfer 
Signed-off-by: Sasha Levin

mips: always link byteswap helpers into decompressor

2021-07-20T14:10:53+00:00

[ Upstream commit cddc40f5617e53f97ef019d5b29c1bd6cbb031ec ]

My series to clean up the unaligned access implementation
across architectures caused some mips randconfig builds to
fail with:

   mips64-linux-ld: arch/mips/boot/compressed/decompress.o: in function `decompress_kernel':
   decompress.c:(.text.decompress_kernel+0x54): undefined reference to `__bswapsi2'

It turns out that this problem has already been fixed for the XZ
decompressor but now it also shows up in (at least) LZO and LZ4.  From my
analysis I concluded that the compiler could always have emitted those
calls, but the different implementation allowed it to make otherwise
better decisions about not inlining the byteswap, which results in the
link error when the out-of-line code is missing.

While it could be addressed by adding it to the two decompressor
implementations that are known to be affected, but as this only adds
112 bytes to the kernel, the safer choice is to always add them.

Fixes: c50ec6787536 ("MIPS: zboot: Fix the build with XZ compression on older GCC versions")
Fixes: 0652035a5794 ("asm-generic: unaligned: remove byteshift helpers")
Link: https://lore.kernel.org/linux-mm/202106301304.gz2wVY9w-lkp@intel.com/
Link: https://lore.kernel.org/linux-mm/202106260659.TyMe8mjr-lkp@intel.com/
Link: https://lore.kernel.org/linux-mm/202106172016.onWT6Tza-lkp@intel.com/
Link: https://lore.kernel.org/linux-mm/202105231743.JJcALnhS-lkp@intel.com/
Signed-off-by: Arnd Bergmann 
Signed-off-by: Thomas Bogendoerfer 
Signed-off-by: Sasha Levin

MIPS: fix "mipsel-linux-ld: decompress.c:undefined reference to `memmove'"

2021-07-19T06:53:16+00:00

This is _not_ an upstream commit and just for 5.4.y only.

kernel test robot reported a 5.4.y build issue found by randconfig [1]
after backporting commit 89b158635ad7 ("lib/lz4: explicitly support
in-place decompression"") due to "undefined reference to `memmove'".

However, upstream and 5.10 LTS seem fine. After digging further,
I found commit a510b616131f ("MIPS: Add support for ZSTD-compressed
kernels") introduced memmove() occasionally and it has been included
since v5.10.

This partially cherry-picks the memmove() part of commit a510b616131f
to fix the reported build regression since we don't need the whole
patch for 5.4 LTS at all.

[1] https://lore.kernel.org/r/202107070120.6dOj1kB7-lkp@intel.com/
Fixes: defcc2b5e54a ("lib/lz4: explicitly support in-place decompression") # 5.4.y
Reported-by: kernel test robot 
Signed-off-by: Gao Xiang 
Signed-off-by: Greg Kroah-Hartman

MIPS: set mips32r5 for virt extensions

2021-07-19T06:53:13+00:00

[ Upstream commit c994a3ec7ecc8bd2a837b2061e8a76eb8efc082b ]

Clang's integrated assembler only accepts these instructions when the
cpu is set to mips32r5. With this change, we can assemble
malta_defconfig with Clang via `make LLVM_IAS=1`.

Link: https://github.com/ClangBuiltLinux/linux/issues/763
Reported-by: Dmitry Golovin 
Signed-off-by: Nick Desaulniers 
Signed-off-by: Thomas Bogendoerfer 
Signed-off-by: Sasha Levin

MIPS: loongsoon64: Reserve memory below starting pfn to prevent Oops

2021-07-19T06:53:13+00:00

[ Upstream commit 6817c944430d00f71ccaa9c99ff5b0096aeb7873 ]

The cause of the problem is as follows:
1. when cat /sys/devices/system/memory/memory0/valid_zones,
   test_pages_in_a_zone() will be called.
2. test_pages_in_a_zone() finds the zone according to stat_pfn = 0.
   The smallest pfn of the numa node in the mips architecture is 128,
   and the page corresponding to the previous 0~127 pfn is not
   initialized (page->flags is 0xFFFFFFFF)
3. The nid and zonenum obtained using page_zone(pfn_to_page(0)) are out
   of bounds in the corresponding array,
   &NODE_DATA(page_to_nid(page))->node_zones[page_zonenum(page)],
   access to the out-of-bounds zone member variables appear abnormal,
   resulting in Oops.
Therefore, it is necessary to keep the page between 0 and the minimum
pfn to prevent Oops from appearing.

Signed-off-by: zhanglianjie 
Signed-off-by: Thomas Bogendoerfer 
Signed-off-by: Sasha Levin

MIPS: add PMD table accounting into MIPS'pmd_alloc_one

2021-07-19T06:53:12+00:00

[ Upstream commit ed914d48b6a1040d1039d371b56273d422c0081e ]

This fixes Page Table accounting bug.

MIPS is the ONLY arch just defining __HAVE_ARCH_PMD_ALLOC_ONE alone.
Since commit b2b29d6d011944 (mm: account PMD tables like PTE tables),
"pmd_free" in asm-generic with PMD table accounting and "pmd_alloc_one"
in MIPS without PMD table accounting causes PageTable accounting number
negative, which read by global_zone_page_state(), always returns 0.

Signed-off-by: Huang Pei 
Signed-off-by: Thomas Bogendoerfer 
Signed-off-by: Sasha Levin

hugetlb: clear huge pte during flush function on mips platform

2021-07-19T06:53:08+00:00

[ Upstream commit 33ae8f801ad8bec48e886d368739feb2816478f2 ]

If multiple threads are accessing the same huge page at the same
time, hugetlb_cow will be called if one thread write the COW huge
page. And function huge_ptep_clear_flush is called to notify other
threads to clear the huge pte tlb entry. The other threads clear
the huge pte tlb entry and reload it from page table, the reload
huge pte entry may be old.

This patch fixes this issue on mips platform, and it clears huge
pte entry before notifying other threads to flush current huge
page entry, it is similar with other architectures.

Signed-off-by: Bibo Mao 
Signed-off-by: Thomas Bogendoerfer 
Signed-off-by: Sasha Levin

MIPS: Fix PKMAP with 32-bit MIPS huge page support

2021-07-14T14:53:36+00:00

[ Upstream commit cf02ce742f09188272bcc8b0e62d789eb671fc4c ]

When 32-bit MIPS huge page support is enabled, we halve the number of
pointers a PTE page holds, making its last half go to waste.
Correspondingly, we should halve the number of kmap entries, as we just
initialized only a single pte table for that in pagetable_init().

Fixes: 35476311e529 ("MIPS: Add partial 32-bit huge page support")
Signed-off-by: Wei Li 
Signed-off-by: Thomas Bogendoerfer 
Signed-off-by: Sasha Levin