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

[Jeff Law]

On 11/6/25 6:56 PM, Peter Bergner wrote:
> 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!]
IMHO that's probably the *only* way this can work reliably due to the 
installation of the final target into the PLT as ifuncs get resolved as 
well as the cached bits in the vDSO.  Once an ifunc is resolved, all 
bets are off on prctl being able to undo that resolution.


> 
> 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.
Agreed.

jeff