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

[Vineet Gupta]

On 11/5/25 16:08, Vineet Gupta wrote:
> On 11/5/25 11:36, Jeff Law wrote:
>> On 11/5/25 12:23 PM, Darius Rad wrote:
>>
>>>> We've had approval for the riscv probe stuff for roughly a year, the only
>>>> reason it hasn't moved forward is I didn't have the time to push the
>>>> approved patch into the tree.  Yao has kindly picked up the effort and it's
>>>> ready to move forward.   hwprobe is the approved mechanism to handle this
>>>> stuff across the various relevant projects.  If there's capabilities missing
>>>> in that interface, then that's what needs to be fixed.  But we shouldn't
>>>> make perfect be the enemy of the good IMHO.
>>> So do that first, or use dl_hwcap until it is available.  Don't break
>>> something that's working.
>> But that is precisely the code you are insisting Yao change.  That code 
>> uses hwprobe in both paths and totally avoids dl_hwcap per the agreed 
>> upon design.
>>
>> User space turning the vector unit on/off, while interesting, should not 
>> drive this discussion.  That needs to go back to the kernel and glibc 
>> teams to figure out if/how it should be supported within the hwprobe 
>> framework.
> Perhaps I'm wrong, but I feel obliged to interject my 2 cents :  Do we have a
> real issue here ?
>
> Quoting Darius' original concern
>
> " This patch certainly has regressions compared with glibc master.
> Presently, if one has an environment that implements the vector extension, but
> it is disabled at runtime with prctl, glibc will operate properly. After this
> patch, running in such an environment will trigger an illegal instruction fault
> whenever memset is run."
>
> Vector unit being turned off at the beginning is just an implementation detail
> to lazily enable it (using fault on first use).
> So prctl's initial disable/enable state doesn't matter IMO. The ifunc selector
> would use hwprobe and see if kernel is advertising V as available. If it
> available, but disabled by prctl, it should still go ahead with wiring up the V
> variants - first use and fault will just work.
>
> Am I missing something here ?

Ah I see the concern: On a V advertised by hwprobe, we wire up the V ifuncs, but
then later in the code user calls the prctl to disable V  directly or though
inheritance etc.
Or is it something else ?

-Vineet