kernel/linux.git/arch/mips, branch linux-5.9.y

sched/idle: Fix arch_cpu_idle() vs tracing

2020-12-16T09:58:32+00:00

[ Upstream commit 58c644ba512cfbc2e39b758dd979edd1d6d00e27 ] We call arch_cpu_idle() with RCU disabled, but then use local_irq_{en,dis}able(), which invokes tracing, which relies on RCU. Switch all arch_cpu_idle() implementations to use raw_local_irq_{en,dis}able() and carefully manage the lockdep,rcu,tracing state like we do in entry. (XXX: we really should change arch_cpu_idle() to not return with interrupts enabled) Reported-by: Sven Schnelle Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Mark Rutland Tested-by: Mark Rutland Link: https://lkml.kernel.org/r/20201120114925.594122626@infradead.org Signed-off-by: Sasha Levin

arch: pgtable: define MAX_POSSIBLE_PHYSMEM_BITS where needed

2020-12-02T07:51:54+00:00

[ Upstream commit cef397038167ac15d085914493d6c86385773709 ] Stefan Agner reported a bug when using zsram on 32-bit Arm machines with RAM above the 4GB address boundary: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = a27bd01c [00000000] *pgd=236a0003, *pmd=1ffa64003 Internal error: Oops: 207 [#1] SMP ARM Modules linked in: mdio_bcm_unimac(+) brcmfmac cfg80211 brcmutil raspberrypi_hwmon hci_uart crc32_arm_ce bcm2711_thermal phy_generic genet CPU: 0 PID: 123 Comm: mkfs.ext4 Not tainted 5.9.6 #1 Hardware name: BCM2711 PC is at zs_map_object+0x94/0x338 LR is at zram_bvec_rw.constprop.0+0x330/0xa64 pc : [] lr : [] psr: 60000013 sp : e376bbe0 ip : 00000000 fp : c1e2921c r10: 00000002 r9 : c1dda730 r8 : 00000000 r7 : e8ff7a00 r6 : 00000000 r5 : 02f9ffa0 r4 : e3710000 r3 : 000fdffe r2 : c1e0ce80 r1 : ebf979a0 r0 : 00000000 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 30c5383d Table: 235c2a80 DAC: fffffffd Process mkfs.ext4 (pid: 123, stack limit = 0x495a22e6) Stack: (0xe376bbe0 to 0xe376c000) As it turns out, zsram needs to know the maximum memory size, which is defined in MAX_PHYSMEM_BITS when CONFIG_SPARSEMEM is set, or in MAX_POSSIBLE_PHYSMEM_BITS on the x86 architecture. The same problem will be hit on all 32-bit architectures that have a physical address space larger than 4GB and happen to not enable sparsemem and include asm/sparsemem.h from asm/pgtable.h. After the initial discussion, I suggested just always defining MAX_POSSIBLE_PHYSMEM_BITS whenever CONFIG_PHYS_ADDR_T_64BIT is set, or provoking a build error otherwise. This addresses all configurations that can currently have this runtime bug, but leaves all other configurations unchanged. I looked up the possible number of bits in source code and datasheets, here is what I found: - on ARC, CONFIG_ARC_HAS_PAE40 controls whether 32 or 40 bits are used - on ARM, CONFIG_LPAE enables 40 bit addressing, without it we never support more than 32 bits, even though supersections in theory allow up to 40 bits as well. - on MIPS, some MIPS32r1 or later chips support 36 bits, and MIPS32r5 XPA supports up to 60 bits in theory, but 40 bits are more than anyone will ever ship - On PowerPC, there are three different implementations of 36 bit addressing, but 32-bit is used without CONFIG_PTE_64BIT - On RISC-V, the normal page table format can support 34 bit addressing. There is no highmem support on RISC-V, so anything above 2GB is unused, but it might be useful to eventually support CONFIG_ZRAM for high pages. Fixes: 61989a80fb3a ("staging: zsmalloc: zsmalloc memory allocation library") Fixes: 02390b87a945 ("mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS") Acked-by: Thomas Bogendoerfer Reviewed-by: Stefan Agner Tested-by: Stefan Agner Acked-by: Mike Rapoport Link: https://lore.kernel.org/linux-mm/bdfa44bf1c570b05d6c70898e2bbb0acf234ecdf.1604762181.git.stefan@agner.ch/ Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin

MIPS: Alchemy: Fix memleak in alchemy_clk_setup_cpu

2020-11-24T12:39:02+00:00

[ Upstream commit ac3b57adf87ad9bac7e33ca26bbbb13fae1ed62b ] If the clk_register fails, we should free h before function returns to prevent memleak. Fixes: 474402291a0ad ("MIPS: Alchemy: clock framework integration of onchip clocks") Reported-by: Hulk Robot Signed-off-by: Zhang Qilong Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin

MIPS: export has_transparent_hugepage() for modules

2020-11-24T12:38:56+00:00

[ Upstream commit 31b4d8e172f614adc53ddecb4b6b2f6411a49b84 ] MIPS should export its local version of "has_transparent_hugepage" so that loadable modules (dax) can use it. Fixes this build error: ERROR: modpost: "has_transparent_hugepage" [drivers/dax/dax.ko] undefined! Fixes: fd8cfd300019 ("arch: fix has_transparent_hugepage()") Reported-by: kernel test robot Signed-off-by: Randy Dunlap Cc: Thomas Bogendoerfer Cc: linux-mips@vger.kernel.org Cc: Dan Williams Cc: Vishal Verma Cc: Dave Jiang Cc: linux-nvdimm@lists.01.org Cc: Hugh Dickins Cc: Andrew Morton Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin

kbuild: explicitly specify the build id style

2020-11-18T18:22:07+00:00

[ Upstream commit a968433723310f35898b4a2f635a7991aeef66b1 ] ld's --build-id defaults to "sha1" style, while lld defaults to "fast". The build IDs are very different between the two, which may confuse programs that reference them. Signed-off-by: Bill Wendling Acked-by: David S. Miller Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

MIPS: configs: lb60: Fix defconfig not selecting correct board

2020-11-05T10:51:44+00:00

commit 7487abbe85afd02c35c283315cefc5e19c28d40f upstream. Since INGENIC_GENERIC_BOARD was introduced, the JZ4740_QI_LB60 option is no longer the default, so the symbol has to be selected by the defconfig, otherwise the kernel built will be for a generic Ingenic board and won't have the Device Tree blob built-in. Cc: stable@vger.kernel.org # v5.7 Fixes: 62249209a772 ("MIPS: ingenic: Default to a generic board") Signed-off-by: Paul Cercueil Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman

MIPS: DEC: Restore bootmem reservation for firmware working memory area

2020-11-05T10:51:43+00:00

commit cf3af0a4d3b62ab48e0b90180ea161d0f5d4953f upstream. Fix a crash on DEC platforms starting with: VFS: Mounted root (nfs filesystem) on device 0:11. Freeing unused PROM memory: 124k freed BUG: Bad page state in process swapper pfn:00001 page:(ptrval) refcount:0 mapcount:-128 mapping:00000000 index:0x1 pfn:0x1 flags: 0x0() raw: 00000000 00000100 00000122 00000000 00000001 00000000 ffffff7f 00000000 page dumped because: nonzero mapcount Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 5.9.0-00858-g865c50e1d279 #1 Stack : 8065dc48 0000000b 8065d2b8 9bc27dcc 80645bfc 9bc259a4 806a1b97 80703124 80710000 8064a900 00000001 80099574 806b116c 1000ec00 9bc27d88 806a6f30 00000000 00000000 80645bfc 00000000 31232039 80706ba4 2e392e35 8039f348 2d383538 00000070 0000000a 35363867 00000000 806c2830 80710000 806b0000 80710000 8064a900 00000001 81000000 00000000 00000000 8035af2c 80700000 ... Call Trace: [<8004bc5c>] show_stack+0x34/0x104 [<8015675c>] bad_page+0xfc/0x128 [<80157714>] free_pcppages_bulk+0x1f4/0x5dc [<801591cc>] free_unref_page+0xc0/0x130 [<8015cb04>] free_reserved_area+0x144/0x1d8 [<805abd78>] kernel_init+0x20/0x100 [<80046070>] ret_from_kernel_thread+0x14/0x1c Disabling lock debugging due to kernel taint caused by an attempt to free bootmem space that as from commit b93ddc4f9156 ("mips: Reserve memory for the kernel image resources") has not been anymore reserved due to the removal of generic MIPS arch code that used to reserve all the memory from the beginning of RAM up to the kernel load address. This memory does need to be reserved on DEC platforms however as it is used by REX firmware as working area, as per the TURBOchannel firmware specification[1]: Table 2-2 REX Memory Regions ------------------------------------------------------------------------- Starting Ending Region Address Address Use ------------------------------------------------------------------------- 0 0xa0000000 0xa000ffff Restart block, exception vectors, REX stack and bss 1 0xa0010000 0xa0017fff Keyboard or tty drivers 2 0xa0018000 0xa001f3ff 1) CRT driver 3 0xa0020000 0xa002ffff boot, cnfg, init and t objects 4 0xa0020000 0xa002ffff 64KB scratch space ------------------------------------------------------------------------- 1) Note that the last 3 Kbytes of region 2 are reserved for backward compatibility with previous system software. ------------------------------------------------------------------------- (this table uses KSEG2 unmapped virtual addresses, which in the MIPS architecture are offset from physical addresses by a fixed value of 0xa0000000 and therefore the regions referred do correspond to the beginning of the physical address space) and we call into the firmware on several occasions throughout the bootstrap process. It is believed that pre-REX firmware used with non-TURBOchannel DEC platforms has the same requirements, as hinted by note #1 cited. Recreate the discarded reservation then, in DEC platform code, removing the crash. References: [1] "TURBOchannel Firmware Specification", On-line version, EK-TCAAD-FS-004, Digital Equipment Corporation, January 1993, Chapter 2 "System Module Firmware", p. 2-5 Signed-off-by: Maciej W. Rozycki Fixes: b93ddc4f9156 ("mips: Reserve memory for the kernel image resources") Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: Greg Kroah-Hartman Signed-off-by: Thomas Bogendoerfer

Merge tag 'mips_fixes_5.9_3' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux

2020-09-25T22:24:04+00:00

Pull MIPS fixes from Thomas Bogendoerfer: - fixed FP register access on Loongsoon-3 - added missing 1074 cpu handling - fixed Loongson2ef build error * tag 'mips_fixes_5.9_3' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: MIPS: BCM47XX: Remove the needless check with the 1074K MIPS: Add the missing 'CPU_1074K' into __get_cpu_type() MIPS: Loongson2ef: Disable Loongson MMI instructions MIPS: Loongson-3: Fix fp register access if MSA enabled

MIPS: BCM47XX: Remove the needless check with the 1074K

2020-09-23T12:48:53+00:00

As there is no known soc powered by mips 1074K in bcm47xx series, the check with 1074K is needless. So just remove it. Link: https://wireless.wiki.kernel.org/en/users/Drivers/b43/soc Fixes: 442e14a2c55e ("MIPS: Add 1074K CPU support explicitly.") Signed-off-by: Wei Li Acked-by: Rafał Miłecki Signed-off-by: Thomas Bogendoerfer

MIPS: Add the missing 'CPU_1074K' into __get_cpu_type()

2020-09-23T12:48:30+00:00

Commit 442e14a2c55e ("MIPS: Add 1074K CPU support explicitly.") split 1074K from the 74K as an unique CPU type, while it missed to add the 'CPU_1074K' in __get_cpu_type(). So let's add it back. Fixes: 442e14a2c55e ("MIPS: Add 1074K CPU support explicitly.") Signed-off-by: Wei Li Signed-off-by: Thomas Bogendoerfer