Re: [PATCH 1/2] riscv: hwprobe: export the availability of vector to user

* Andy Chiu:

Userland IFUNC resolvers use hwprobe to decide whether to dispatch to
vectorized routines. But RISCV_HWPROBE_KEY_IMA_EXT_0 only reports what
is present in hardware, not what the calling process may actually use:
when Vector is disabled for a process via
prctl(PR_RISCV_V_SET_CONTROL, PR_RISCV_V_VSTATE_CTRL_OFF), it is still
reported as present. A resolver that trusts this and runs a vector
instruction crashes with SIGILL.

Add RISCV_HWPROBE_KEY_EXT_ENABLED, a positional modifier key that carries
no value of its own. Within a single request, keys placed after it report
extensions that are both present and enabled for the calling process,
while keys before it keep reporting hardware presence. This masks out V
and its V-dependent sub-extensions when V is disabled for the process, and
lets userland obtain both views in one query:

      [ {IMA_EXT_0}, {EXT_ENABLED}, {IMA_EXT_0} ]
          present       modifier       enabled

The enabled view depends on per-process state, so it cannot be served from
the vDSO's process-independent cache; requests carrying the modifier are
deferred to the syscall. Unknown keys are still reported as -1, so the
feature is detectable and existing users are unaffected.

What is the expected behavior if RISCV_HWPROBE_KEY_EXT_ENABLED is not
supported?

We only get a true userspace simplification over hwprobe + prctl if we
can disable vector extension usage if the kernel does not support
RISCV_HWPROBE_KEY_EXT_ENABLED (so a V usage regression for older
kernels).  Otherwise we'd have to use the new approach and, as a
fallback, the old combination of hwprobe and prctl.

Thanks,
Florian