ucontext, kernel vs. userspace (glibc)

[Mark Brown]

On Fri, Sep 03, 2021 at 05:14:28PM +1000, Benjamin Herrenschmidt wrote:

> 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.  */

The kernel does generate a FPSIMD context in addition to any SVE context
for compatibility, though that doesn't mean you can actually fully
restore them successfully with glibc.  For contexts generated by glibc
note that unless a function signature involves a SVE type the SVE
register contents are caller saved:

   https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#id48

so glibc will be fine just ignoring SVE when it generates contexts given
that it'll be doing that inside a non-SVE function call.

Like Szabolcs says BTI is going to cause issues restoring kernel
generated contexts even without extensions like SVE adding extra
register state.

> > 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.

Indeed, it'd have to be joined up with an increase of the userspace
ucontext.

> 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.

Yes, the current context should be big enough for 512 bit SVE - that's
why the kernel clamps the default SVE vector length to 512 bits, so we
sidestep these issues by default even if the user happens to have a
system that can do larger vector lengths.  Not an immediate issue with
actual hardware in any case, though that code currently kicks in on
qemu's cpu=max.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210903/17a91b94/attachment-0001.sig>