Messages in this thread | | | From | Rémi Denis-Courmont <> | Subject | Re: [PATCH -next v20 20/26] riscv: Add prctl controls for userspace vector management | Date | Wed, 24 May 2023 19:13:10 +0300 |
| |
Le keskiviikkona 24. toukokuuta 2023, 3.18.26 EEST Palmer Dabbelt a écrit : > > 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?
That is one possibility that I can live, although it feels unnecessarily user- hostile compared to setting it only if the process _started_ with V enabled.
> 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?
Maybe; I must admit I have zero visibility to RVI inner workings. At least C, D and F bits could work for JIT use cases, I suppose. E and M are totally impractical to support. G, I, X and Z cannot are already wasted by the design, and I guess we will now waste all 16 others.
But as for V, what is the user-space story for the prctl()? Who is intended to enablet V mode? If there is no clear story, it is all but guaranteed that random libraries will call it, and just _blindly_ assume that there is enough stack space for signal handling. If so, then there is not much point having a prctl() in the first place; might as well stick to just a kernel Kconfig with no runtime configuration.
-- Rémi Denis-Courmont http://www.remlab.net/
| |