* 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