Messages in this thread | | | From | Andy Chiu <> | Date | Mon, 22 May 2023 16:28:28 +0800 | Subject | Re: [PATCH -next v20 20/26] riscv: Add prctl controls for userspace vector management |
| |
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.
> > 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
| |