On Wed, 12 Aug 2026 19:33:57 -0400, Guodong Xu wrote: > [...] > > diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys_hwprobe.c > index 656cb100ac48..a18465e734b5 100644 > --- a/arch/riscv/kernel/sys_hwprobe.c > +++ b/arch/riscv/kernel/sys_hwprobe.c > > [...] > > case RISCV_HWPROBE_KEY_BASE_BEHAVIOR: > - pair->value = RISCV_HWPROBE_BASE_BEHAVIOR_IMA; > + pair->value = 0;
Today while testing this series with glibc's glibc IFUNC resolver on QEMU (-cpu rva23s64), I found that this hunk introduces an initialization ordering bug, which affects the KEY_BASE_BEHAVIOR valude in vDSO. > + if (hwprobe_has_isa_base(cpus, RISCV_ISA_BASE_IMA)) > + pair->value |= RISCV_HWPROBE_BASE_BEHAVIOR_IMA; > + if (hwprobe_has_isa_base(cpus, RISCV_ISA_BASE_RVA23U64)) > + pair->value |= RISCV_HWPROBE_BASE_BEHAVIOR_RVA23U64; > break; Both bits are now derived from hart_isa[cpu].isa_bases, which patch v6 09/11 populates in riscv_init_isa_bases() at subsys_initcall. The vDSO snapshot of all hwprobe values, init_hwprobe_vdso_data(), runs at arch_initcall_sync, which is earlier. So the vDSO copy of RISCV_HWPROBE_KEY_BASE_BEHAVIOR is taken from empty bitmaps and reads 0: raw syscall : key=3 value=0x3 (IMA | RVA23U64) __riscv_hwprobe (vDSO) : key=3 value=0x0 Mainline returns 0x1 on both paths, so this also regresses the IMA bit for every vDSO user of key 3. The selftests did not catch it because they call the system call directly (sys_hwprobe.S); glibc's __riscv_hwprobe() takes the vDSO fast path and did. The fix is to register riscv_init_isa_bases() at arch_initcall instead of subsys_initcall. That is still after core_initcall(tagged_addr_init), which it depends on, and before arch_initcall_sync. It belongs in patch 09/11 and I will fold it in there in v7. With it both paths return 0x3, and the hwprobe, cbo and which-cpus selftests pass on rva23s64, rva22s64 and on mainline. I will send v7. Thanks for your patience. BR, Guodong
