[PATCH v1 1/1] riscv: Add RVV memset via multiarch/IFUNC

[Peter Bergner]

On 10/31/25 9:25 AM, Yao Zihong wrote:
> My understanding is that the kernel may eventually make riscv_hwprobe
> reflect whether an extension is enabled, not just present, but that is
> not the case today.
> 
> I’m unsure whether it is glibc’s responsibility to cover this gap in the
> meantime.
> If it is, then perhaps we should gate the RVV path on both riscv_hwprobe
> (to ensure V = 1.0 capability) and dl_hwcap.V (to respect per-process enablement
> via prctl/sysctl).
> 
> Do you think this should be handled in glibc or left for the kernel side?

I don't think glibc can fix this/cover the gap.  My guess is the common use
case of using prctl to disable vector (or some other extension) would be
to call prctl and then exec a child process that would inherit the change.
[Not to say the use case itself is common!]
In that case, the child process and its glibc would never see the parent's
prctl call that disabled vector, but its hwprobe query would still say that
vector is enabled, leading to a SIGILL when it tries to execute a vector
instruction.

    bergner@bananapif3:~$ ./march-test.out
    Some enabled risc-v extensions: rv64imafdcv
    Executed a vector instruction.
    bergner@bananapif3:~$ ./riscv-disable-vec ./march-test.out
    Some enabled risc-v extensions: rv64imafdcv
    Illegal instruction

I think the only solution that makes sense here, is for the kernel to modify
hwprobe so that it doesn't show vector (or some other extension) when prctl
has disabled vector (or some other extension).  I'm actually surprised it
doesn't already operate that way.


Peter