kernel.git/arch/loongarch, branch 0x221E-v0.0-v7.0

LoongArch: KVM: Fix base address calculation in kvm_eiointc_regs_access()

2026-03-26T06:29:09Z

In function kvm_eiointc_regs_access(), the register base address is caculated from array base address plus offset, the offset is absolute value from the base address. The data type of array base address is u64, it should be converted into the "void *" type and then plus the offset. Cc: Fixes: d3e43a1f34ac ("LoongArch: KVM: Use 64-bit register definition for EIOINTC"). Reported-by: Aurelien Jarno Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1131431 Signed-off-by: Bibo Mao Signed-off-by: Huacai Chen

LoongArch: KVM: Handle the case that EIOINTC's coremap is empty

2026-03-26T06:29:09Z

EIOINTC's coremap in eiointc_update_sw_coremap() can be empty, currently we get a cpuid with -1 in this case, but we actually need 0 because it's similar as the case that cpuid >= 4. This fix an out-of-bounds access to kvm_arch::phyid_map::phys_map[]. Cc: Fixes: 3956a52bc05bd81 ("LoongArch: KVM: Add EIOINTC read and write functions") Reported-by: Aurelien Jarno Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1131431 Signed-off-by: Huacai Chen

LoongArch: KVM: Make kvm_get_vcpu_by_cpuid() more robust

2026-03-26T06:29:09Z

kvm_get_vcpu_by_cpuid() takes a cpuid parameter whose type is int, so cpuid can be negative. Let kvm_get_vcpu_by_cpuid() return NULL for this case so as to make it more robust. This fix an out-of-bounds access to kvm_arch::phyid_map::phys_map[]. Cc: Fixes: 73516e9da512adc ("LoongArch: KVM: Add vcpu mapping from physical cpuid") Reported-by: Aurelien Jarno Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1131431 Signed-off-by: Huacai Chen

LoongArch: vDSO: Emit GNU_EH_FRAME correctly

2026-03-26T06:29:09Z

With -fno-asynchronous-unwind-tables and --no-eh-frame-hdr (the default of the linker), the GNU_EH_FRAME segment (specified by vdso.lds.S) is empty. This is not valid, as the current DWARF specification mandates the first byte of the EH frame to be the version number 1. It causes some unwinders to complain, for example the ClickHouse query profiler spams the log with messages: clickhouse-server[365854]: libunwind: unsupported .eh_frame_hdr version: 127 at 7ffffffb0000 Here "127" is just the byte located at the p_vaddr (0, i.e. the beginning of the vDSO) of the empty GNU_EH_FRAME segment. Cross- checking with /proc/365854/maps has also proven 7ffffffb0000 is the start of vDSO in the process VM image. In LoongArch the -fno-asynchronous-unwind-tables option seems just a MIPS legacy, and MIPS only uses this option to satisfy the MIPS-specific "genvdso" program, per the commit cfd75c2db17e ("MIPS: VDSO: Explicitly use -fno-asynchronous-unwind-tables"). IIRC it indicates some inherent limitation of the MIPS ELF ABI and has nothing to do with LoongArch. So we can simply flip it over to -fasynchronous-unwind-tables and pass --eh-frame-hdr for linking the vDSO, allowing the profilers to unwind the stack for statistics even if the sample point is taken when the PC is in the vDSO. However simply adjusting the options above would exploit an issue: when the libgcc unwinder saw the invalid GNU_EH_FRAME segment, it silently falled back to a machine-specific routine to match the code pattern of rt_sigreturn() and extract the registers saved in the sigframe if the code pattern is matched. As unwinding from signal handlers is vital for libgcc to support pthread cancellation etc., the fall-back routine had been silently keeping the LoongArch Linux systems functioning since Linux 5.19. But when we start to emit GNU_EH_FRAME with the correct format, fall-back routine will no longer be used and libgcc will fail to unwind the sigframe, and unwinding from signal handlers will no longer work, causing dozens of glibc test failures. To make it possible to unwind from signal handlers again, it's necessary to code the unwind info in __vdso_rt_sigreturn via .cfi_* directives. The offsets in the .cfi_* directives depend on the layout of struct sigframe, notably the offset of sigcontext in the sigframe. To use the offset in the assembly file, factor out struct sigframe into a header to allow asm-offsets.c to output the offset for assembly. To work around a long-term issue in the libgcc unwinder (the pc is unconditionally substracted by 1: doing so is technically incorrect for a signal frame), a nop instruction is included with the two real instructions in __vdso_rt_sigreturn in the same FDE PC range. The same hack has been used on x86 for a long time. Cc: stable@vger.kernel.org Fixes: c6b99bed6b8f ("LoongArch: Add VDSO and VSYSCALL support") Signed-off-by: Xi Ruoyao Signed-off-by: Huacai Chen

LoongArch: Workaround LS2K/LS7A GPU DMA hang bug

2026-03-26T06:29:09Z

1. Hardware limitation: GPU, DC and VPU are typically PCI device 06.0, 06.1 and 06.2. They share some hardware resources, so when configure the PCI 06.0 device BAR1, DMA memory access cannot be performed through this BAR, otherwise it will cause hardware abnormalities. 2. In typical scenarios of reboot or S3/S4, DC access to memory through BAR is not prohibited, resulting in GPU DMA hangs. 3. Workaround method: When configuring the 06.0 device BAR1, turn off the memory access of DC, GPU and VPU (via DC's CRTC registers). Cc: stable@vger.kernel.org Signed-off-by: Qianhai Wu Signed-off-by: Huacai Chen

LoongArch: Fix missing NULL checks for kstrdup()

2026-03-26T06:29:08Z

1. Replace "of_find_node_by_path("/")" with "of_root" to avoid multiple calls to "of_node_put()". 2. Fix a potential kernel oops during early boot when memory allocation fails while parsing CPU model from device tree. Cc: stable@vger.kernel.org Signed-off-by: Li Jun Signed-off-by: Huacai Chen

LoongArch: KVM: Fix typo issue in kvm_vm_init_features()

2026-03-16T02:36:02Z

Most of VM feature detections are integer OR operations, and integer assignment operation will clear previous integer OR operation. So here change all integer assignment operations to integer OR operations. Fixes: 82db90bf461b ("LoongArch: KVM: Move feature detection in kvm_vm_init_features()") Signed-off-by: Bibo Mao Signed-off-by: Huacai Chen

LoongArch: BPF: Make arch_protect_bpf_trampoline() return 0

2026-03-16T02:36:01Z

Occasionally there exist "text_copy_cb: operation failed" when executing the bpf selftests, the reason is copy_to_kernel_nofault() failed and the ecode of ESTAT register is 0x4 (PME: Page Modification Exception) due to the pte is not writeable. The root cause is that there is another place to set the pte entry as readonly which is in the generic weak version of arch_protect_bpf_trampoline(). There are two ways to fix this race condition issue: the direct way is to modify the generic weak arch_protect_bpf_trampoline() to add a mutex lock for set_memory_rox(), but the other simple and proper way is to just make arch_protect_bpf_trampoline() return 0 in the arch-specific code because LoongArch has already use the BPF prog pack allocator for trampoline. Here are the trimmed kernel log messages: copy_to_kernel_nofault: memory access failed, ecode 0x4 copy_to_kernel_nofault: the caller is text_copy_cb+0x50/0xa0 text_copy_cb: operation failed ------------[ cut here ]------------ bpf_prog_pack bug: missing bpf_arch_text_invalidate? WARNING: kernel/bpf/core.c:1008 at bpf_prog_pack_free+0x200/0x228 ... Call Trace: [<9000000000248914>] show_stack+0x64/0x188 [<9000000000241308>] dump_stack_lvl+0x6c/0x9c [<90000000002705bc>] __warn+0x9c/0x200 [<9000000001c428c0>] __report_bug+0xa8/0x1c0 [<9000000001c42b5c>] report_bug+0x64/0x120 [<9000000001c7dcd0>] do_bp+0x270/0x3c0 [<9000000000246f40>] handle_bp+0x120/0x1c0 [<900000000047b030>] bpf_prog_pack_free+0x200/0x228 [<900000000047b2ec>] bpf_jit_binary_pack_free+0x24/0x60 [<900000000026989c>] bpf_jit_free+0x54/0xb0 [<900000000029e10c>] process_one_work+0x184/0x610 [<900000000029ef8c>] worker_thread+0x24c/0x388 [<90000000002a902c>] kthread+0x13c/0x170 [<9000000001c7dfe8>] ret_from_kernel_thread+0x28/0x1c0 [<9000000000246624>] ret_from_kernel_thread_asm+0xc/0x88 ---[ end trace 0000000000000000 ]--- Here is a simple shell script to reproduce: #!/bin/bash for ((i=1; i<=1000; i++)) do echo "Under testing $i ..." dmesg -c > /dev/null ./test_progs -t fentry_attach_stress > /dev/null dmesg -t | grep "text_copy_cb: operation failed" if [ $? -eq 0 ]; then break fi done Cc: stable@vger.kernel.org Fixes: 4ab17e762b34 ("LoongArch: BPF: Use BPF prog pack allocator") Acked-by: Hengqi Chen Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen

LoongArch: No need to flush icache if text copy failed

2026-03-16T02:36:01Z

If copy_to_kernel_nofault() failed, no need to flush icache and just return immediately. Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen

LoongArch: Check return values for set_memory_{rw,rox}

2026-03-16T02:36:01Z

set_memory_rw() and set_memory_rox() may fail, so we should check the return values and return immediately in larch_insn_text_copy(). Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen