RISCV Vector unit disabled by default for new task (was Re: [PATCH v12 17/17] riscv: prctl to enable vector commands)

[Florian Weimer]

* Darius Rad:

> On Fri, Dec 09, 2022 at 01:32:33PM +0100, Florian Weimer via Libc-alpha wrote:
>> * Darius Rad:
>> 
>> > On Fri, Dec 09, 2022 at 11:02:57AM +0100, Florian Weimer wrote:
>> >> * Andrew Waterman:
>> >> 
>> >> > This suggests that ld.so, early-stage libc, or possibly both will need
>> >> > to make this prctl() call, perhaps by parsing the ELF headers of the
>> >> > binary and each library to determine if the V extension is used.
>> >> 
>> >> If the string functions use the V extension, it will be enabled
>> >> unconditionally.  So I don't see why it's okay for libc to trigger this
>> >> alleged UAPI change, when the kernel can't do it by default.
>> >> 
>> >
>> > Because the call to enable can fail and userspace needs to deal with that.
>> 
>> Failure is usually indicated by an AT_HWCAP or AT_HWCAP2 bit remaining
>> zero, or perhaps a special CPU register (although that is more unusual).
>
> That would indicate that the extension is not present, which is one of, but
> not the only way it can fail.

I think you should bring down the number of failure modes.  HWCAP has
the advantage that it communicates kernel/hypervisor/firmware/CPU
support in a single bit, which simplifies the programming model and
avoids hard-to-detect bugs.  It's not clear why it would be beneficial
to continue on ENOMEM failures here because the system must clearly be
in bad shape at this point, and launching a new process is very unlikely
to improve matters.  So I think the simpler programming model is the way
to go here.

> The vector extension relies on dynamically allocated memory in the kernel,
> which can fail.

But this failure can be reported as part of execve and clone.

> It also provides the opportunity for the kernel to deny access to the
> vector extension, perhaps due to administrative policy or other future
> mechanism.

HWCAP can do this, too.

Thanks,
Florian