Fix the dtc warnings:
arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider
arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider
arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite 'interrupt_provider'
And a runtime warning introduced in commit 045b14ca5c36 ("of: WARN on
deprecated #address-cells/#size-cells handling"):
WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0
Missing '#address-cells' in /bus@10000000/pci@1a000000/pci_bridge@9,0
The fix is similar to commit d89a415ff8d5 ("MIPS: Loongson64: DTS: Fix PCIe
port nodes for ls7a"), which has fixed the issue for ls2k (despite its
subject mentions ls7a).
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: michael <michael5hzg@gmail.com>
Signed-off-by: maoxiaochuan <maoxiaochuan@loongson.cn>
When executing mm selftests run_vmtests.sh, there is such an error:
BUG: Bad page state in process uffd-unit-tests pfn:00000
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x0
flags: 0xffff0000002000(reserved|node=0|zone=0|lastcpupid=0xffff)
raw: 00ffff0000002000 ffffbf0000000008 ffffbf0000000008 0000000000000000
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
Modules linked in: snd_seq_dummy snd_seq snd_seq_device rfkill vfat fat
virtio_balloon efi_pstore virtio_net pstore net_failover failover fuse
nfnetlink virtio_scsi virtio_gpu virtio_dma_buf dm_multipath efivarfs
CPU: 2 UID: 0 PID: 1913 Comm: uffd-unit-tests Not tainted 6.12.0 #184
Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
Stack : 900000047c8ac000 0000000000000000 9000000000223a7c 900000047c8ac000
900000047c8af690 900000047c8af698 0000000000000000 900000047c8af7d8
900000047c8af7d0 900000047c8af7d0 900000047c8af5b0 0000000000000001
0000000000000001 900000047c8af698 10b3c7d53da40d26 0000010000000000
0000000000000022 0000000fffffffff fffffffffe000000 ffff800000000000
000000000000002f 0000800000000000 000000017a6d4000 90000000028f8940
0000000000000000 0000000000000000 90000000025aa5e0 9000000002905000
0000000000000000 90000000028f8940 ffff800000000000 0000000000000000
0000000000000000 0000000000000000 9000000000223a94 000000012001839c
00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d
...
Call Trace:
[<9000000000223a94>] show_stack+0x5c/0x180
[<9000000001c3fd64>] dump_stack_lvl+0x6c/0xa0
[<900000000056aa08>] bad_page+0x1a0/0x1f0
[<9000000000574978>] free_unref_folios+0xbf0/0xd20
[<90000000004e65cc>] folios_put_refs+0x1a4/0x2b8
[<9000000000599a0c>] free_pages_and_swap_cache+0x164/0x260
[<9000000000547698>] tlb_batch_pages_flush+0xa8/0x1c0
[<9000000000547f30>] tlb_finish_mmu+0xa8/0x218
[<9000000000543cb8>] exit_mmap+0x1a0/0x360
[<9000000000247658>] __mmput+0x78/0x200
[<900000000025583c>] do_exit+0x43c/0xde8
[<9000000000256490>] do_group_exit+0x68/0x110
[<9000000000256554>] sys_exit_group+0x1c/0x20
[<9000000001c413b4>] do_syscall+0x94/0x130
[<90000000002216d8>] handle_syscall+0xb8/0x158
Disabling lock debugging due to kernel taint
BUG: non-zero pgtables_bytes on freeing mm: -16384
On LoongArch system, invalid huge pte entry should be invalid_pte_table
or a single _PAGE_HUGE bit rather than a zero value. And it should be
the same with invalid pmd entry, since pmd_none() is called by function
free_pgd_range() and pmd_none() return 0 by huge_pte_clear(). So single
_PAGE_HUGE bit is also treated as a valid pte table and free_pte_range()
will be called in free_pmd_range().
free_pmd_range()
pmd = pmd_offset(pud, addr);
do {
next = pmd_addr_end(addr, end);
if (pmd_none_or_clear_bad(pmd))
continue;
free_pte_range(tlb, pmd, addr);
} while (pmd++, addr = next, addr != end);
Here invalid_pte_table is used for both invalid huge pte entry and
pmd entry.
Cc: stable@vger.kernel.org
Fixes: 09cfefb7fa70 ("LoongArch: Add memory management")
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: michael <michael5hzg@gmail.com>
Signed-off-by: maoxiaochuan <maoxiaochuan@loongson.cn>
Performance improvement for reading /proc/interrupts on LoongArch.
On a system with n CPUs and m interrupts, there will be n*m decimal
values yielded via seq_printf(.."%10u "..) which is less efficient than
seq_put_decimal_ull_width(), stress reading /proc/interrupts indicates
~30% performance improvement with this patch (and its friends).
Signed-off-by: David Wang <00107082@163.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: michael <michael5hzg@gmail.com>
Signed-off-by: maoxiaochuan <maoxiaochuan@loongson.cn>
LoongArch has supported PREEMPT_RT now. It uses GENERIC_ENTRY, so just
add the TIF bit (TIF_NEED_RESCHED_LAZY) related definitions and select
the Kconfig symbol (ARCH_HAS_PREEMPT_LAZY) is enough to make it go.
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: michael <michael5hzg@gmail.com>
Signed-off-by: maoxiaochuan <maoxiaochuan@loongson.cn>
Now the min_delta is 0x600 (1536) for LoongArch's constant clockevent
device. For a 100MHz hardware timer this means ~15us. This is a little
big, especially for PREEMPT_RT enabled kernels. So reduce it to 100 for
PREEMPT_RT kernel, and 1000 for others (we don't want too small values
to affect performance).
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: michael <michael5hzg@gmail.com>
Signed-off-by: maoxiaochuan <maoxiaochuan@loongson.cn>
(1) Description of Problem:
When testing BPF JIT with the latest compiler toolchains on LoongArch,
there exist some strange failed test cases, dmesg shows something like
this:
# dmesg -t | grep FAIL | head -1
... ret -3 != -3 (0xfffffffd != 0xfffffffd)FAIL ...
(2) Steps to Reproduce:
# echo 1 > /proc/sys/net/core/bpf_jit_enable
# modprobe test_bpf
(3) Additional Info:
There are no failed test cases compiled with the lower version of GCC
such as 13.3.0, while the problems only appear with higher version of
GCC such as 14.2.0.
This is because the problems were hidden by the lower version of GCC due
to redundant sign extension instructions generated by compiler, but with
optimization of higher version of GCC, the sign extension instructions
have been removed.
(4) Root Cause Analysis:
The LoongArch architecture does not expose sub-registers, and hold all
32-bit values in a sign-extended format. While BPF, on the other hand,
exposes sub-registers, and use zero-extension (similar to arm64/x86).
This has led to some subtle bugs, where a BPF JITted program has not
sign-extended the a0 register (return value in LoongArch land), passed
the return value up the kernel, for example:
| int from_bpf(void);
|
| long foo(void)
| {
| return from_bpf();
| }
Here, a0 would be 0xffffffff instead of the expected 0xffffffffffffffff.
Internally, the LoongArch JIT uses a5 as a dedicated register for BPF
return values. That is to say, the LoongArch BPF uses a5 for BPF return
values, which are zero-extended, whereas the LoongArch ABI uses a0 which
is sign-extended.
(5) Final Solution:
Keep a5 zero-extended, but explicitly sign-extend a0 (which is used
outside BPF land). Because libbpf currently defines the return value
of an ebpf program as a 32-bit unsigned integer, just use addi.w to
extend bit 31 into bits 63 through 32 of a5 to a0. This is similar to
commit 2f1b0d3d7331 ("riscv, bpf: Sign-extend return values").
Fixes: 5dc615520c4d ("LoongArch: Add BPF JIT support")
Acked-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: michael <michael5hzg@gmail.com>
Signed-off-by: maoxiaochuan <maoxiaochuan@loongson.cn>
Whenever I try to build the kernel with upcoming GCC 15 which defaults
to -std=gnu23 I get a build failure:
CC arch/loongarch/vdso/vgetcpu.o
In file included from ./include/uapi/linux/posix_types.h:5,
from ./include/uapi/linux/types.h:14,
from ./include/linux/types.h:6,
from ./include/linux/kasan-checks.h:5,
from ./include/asm-generic/rwonce.h:26,
from ./arch/loongarch/include/generated/asm/rwonce.h:1,
from ./include/linux/compiler.h:317,
from ./include/asm-generic/bug.h:5,
from ./arch/loongarch/include/asm/bug.h:60,
from ./include/linux/bug.h:5,
from ./include/linux/mmdebug.h:5,
from ./include/linux/mm.h:6,
from ./arch/loongarch/include/asm/vdso.h:10,
from arch/loongarch/vdso/vgetcpu.c:6:
./include/linux/stddef.h:11:9: error: expected identifier before 'false'
11 | false = 0,
| ^~~~~
./include/linux/types.h:35:33: error: two or more data types in declaration specifiers
35 | typedef _Bool bool;
| ^~~~
./include/linux/types.h:35:1: warning: useless type name in empty declaration
35 | typedef _Bool bool;
| ^~~~~~~
The kernel builds explicitly with -std=gnu11 in top Makefile, but
arch/loongarch/vdso does not use KBUILD_CFLAGS from the rest of the
kernel, just add -std=gnu11 flag to arch/loongarch/vdso/Makefile.
By the way, commit e8c07082a810 ("Kbuild: move to -std=gnu11") did a
similar change for arch/arm64/kernel/vdso32/Makefile.
Fixes: c6b99bed6b8f ("LoongArch: Add VDSO and VSYSCALL support")
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: michael <michael5hzg@gmail.com>
Signed-off-by: maoxiaochuan <maoxiaochuan@loongson.cn>
LoongArch's toolchain may change the default code model from normal to
medium. This is unnecessary for kernel, and generates some relocations
which cannot be handled by the module loader. So explicitly specify the
code model to normal in Makefile (for Rust 'normal' is 'small').
Cc: stable@vger.kernel.org
Tested-by: Haiyong Sun <sunhaiyong@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: michael <michael5hzg@gmail.com>
Signed-off-by: maoxiaochuan <maoxiaochuan@loongson.cn>
For now, it is time to remove -fno-jump-tables to enable jump table for
objtool if the compiler has -mannotate-tablejump, otherwise it is better
to remain -fno-jump-tables to keep compatibility with older compilers.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: michael <michael5hzg@gmail.com>
Signed-off-by: maoxiaochuan <maoxiaochuan@loongson.cn>
Xi Ruoyao