Re: [PATCH -next v20 20/26] riscv: Add prctl controls for userspace vector management

["Rémi Denis-Courmont" <remi@remlab.net>]

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/