ucontext, kernel vs. userspace (glibc)

[Benjamin Herrenschmidt]

On Thu, 2021-09-02 at 13:42 +0100, Mark Brown wrote:
> On Mon, Aug 30, 2021 at 08:40:03PM +1000, Benjamin Herrenschmidt wrote:
> 
> > So I'm discovering arm64 intricacies and today, as I was looking at SVE
> > support (in the context of distro glibc backports.. don't ask), I
> > noticed that glibc has no provision for dealing with kernel generated
> > ucontext's in its {get,set,swap}_context functions...
> > (It says so explicitly in the code unless I misunderstood).
> > So one thing we did to "solve" this on ppc64 a while ago was to create
> > a swapcontext syscall which can operate as all 3 operations (you can
> > have NULL arguments), which also handles the sigprocmask (bonus:
> > atomically with the context get/set from a userspace perspective).
> > Would it make sense to do something similar on aarch64 ? (And have
> > glibc then exploit it).
> 
> I think the usefulness of such an interface is mainly a question for
> userspace - I don't immediately see any issue with implementing it if
> it's useful to people.

Well, the problem as far as I can tell is that the glibc implementation
of these today. They support "FPSIMD" but that's about it (so no SVE or
anything else) along with a comment:

	/* Check for FP SIMD context.  We don't support restoring
	   contexts created by the kernel, so this context must have
	   been created by getcontext.  Hence we can rely on the
	   first extension block being the FP SIMD context.  */

That said, a bit of reading around seems to indicate that the
expecation of being able to setcontext() back to a signal handler
generated context has been deprecated by the standard and broken on x86
for a while in Linux, so I suppose that is less of an issue.

That said, there is still some advantage in letting the kernel
implement these as it would allow the kernel to support various
"extensions" such as SVE (as long as there is room) transparently
without having to change glibc.

In fact, isn't it possible for glibc to define its own ucontext
structure for applications to use that can potentially have a larger
reserved area ? By passing that size to the syscall, you can
essentially get userspace ready for future extensions... within limits.

> > The hard-to-solve thing is the case where the SVE context spills
> > outside of the ucontext itself, in the extra room on the stack, since
> > programs that "now" about ucontext will not have allocated space for
> > that, so that's more/less a lost cause already.
> 
> You can figure out the maximum possible size for a context so it would
> be possible to define a mechanism for pointing to extra data I guess but
> yeah, it's going to be a problem when we start seeing systems with large
> enough register state.

Extra data for userspace generated ucontext's isn't going to fly much,
there's really no "place" to put it (those things can be part of
structures etc...) and no "hook" to allocate/free sub structures.

So you need whatever struct ucontext is used in userspace to be big
enough.

That said, I think the current one might be enough for sve512 (I need
to check) and we could have glibc define something much bigger (16KB ?)
without much damage I suspect.

Nagyu ? What do you think ?

Cheers,
Ben.