Messages in this thread | | | Date | Tue, 23 May 2023 17:18:26 -0700 (PDT) | Subject | Re: [PATCH -next v20 20/26] riscv: Add prctl controls for userspace vector management | From | Palmer Dabbelt <> |
| |
On Mon, 22 May 2023 02:58:45 PDT (-0700), remi@remlab.net wrote: > Hi, > > Le 22 mai 2023 11:28:28 GMT+03:00, Andy Chiu <andy.chiu@sifive.com> a écrit : >>On Sun, May 21, 2023 at 1:41â¯PM Rémi Denis-Courmont <remi@remlab.net> wrote: >>> >>> Hi all, >>> >>> Le torstaina 18. toukokuuta 2023 19.19.43 EEST, vous avez écrit : >>> > This patch add two riscv-specific prctls, to allow usespace control the >>> > use of vector unit: >>> > >>> > * PR_RISCV_V_SET_CONTROL: control the permission to use Vector at next, >>> > or all following execve for a thread. Turning off a thread's Vector >>> > live is not possible since libraries may have registered ifunc that >>> > may execute Vector instructions. >>> > * PR_RISCV_V_GET_CONTROL: get the same permission setting for the >>> > current thread, and the setting for following execve(s). >>> >>> So far the story was that if the nth bit in the ELF HWCAP auxillary vector was >>> set, then the nth single lettered extension was supported. There is already >>> userspace code out there that expects this of the V bit. (I know I have >>> written such code, and I also know others did likewise.) This is how it >>> already works for the D and F bits. >> >>Yes, the V bit in ELF_HWCAP becomes vague in this series. > > >>> Admittedly, upstream Linux has never ever set that bit to this day. But still, >>> if we end up with the bit set in a process that has had V support disabled by >>> the parent (or the sysctl), existing userspace will encounter SIGILL and >>> break. >>> >>> IMO, the bit must be masked not only whence the kernel lacks V support (as >>> PATCH 02 does), but also if the process starts with V disabled. >> >>This is going to change ELF_HWCAP from a macro to a function. The >>function will turn on COMPAT_HWCAP_ISA_V iff V is supported and >>allowed. I am going to do this in v21 If this looks sane. i.e. >>Currently I don't see other architectures which give different >>ELF_HWCAP values on each execve. If ELF_HWCAP is not a right place to >>encode the information then userspace has to make the prctl() call to >>be certain on whether V is usable. > > I don't think the value of an auxillary vector entry can change in an existing process nor that we need that. If an application starts with V disabled, you can keep the V bit clear even if V gets enabled later on; that won't break existing userspace code, which simply won't use vectors. > > What does break existing userspace is setting the V bit whilst vectors are disabled.
So maybe the right answer is to just not set V at all? The single-letter extensions are sort of defunct now, there's multi-letter sub extensions for most things, but V got ratified with those sub-extensions so we could just call it extra-ambiguous?
> > > >> >>> >>> There are two ways to achieve this: >>> 1) V is never ever set, and userspace is forced to use hwprobe() instead. >>> 2) V is set only in processes starting with V enabled (and it's their own >>> fault if they disabled it in future child threads). >> >>The prctl() interface does not allow processes to turn off V once it >>is enabled in its current (execve) context. The process can only >>disable V when the next execve() happens. Then, if we implement >>ELF_HWCAP as mentioned above, the kernel will reload a new HWCAP for >>the process. By then, the new HWCAP will have V masked since it is not >>allowed. >> >>> >>> Br, >>> >>> -- >>> ã¬ãã»ãã-ã¯ãŒã«ã¢ã³ >>> http://www.remlab.net/ >>> >>> >>> >>> >>> _______________________________________________ >>> linux-riscv mailing list >>> linux-riscv@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-riscv >> >>Thanks, >>Andy >>
| |