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

Rémi Denis-Courmont
2023-05-24T16:13:30Z

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