[PATCH] arm64: signal: Update sigcontext reservations table

Will Deacon will at kernel.org
Tue Aug 20 06:37:40 PDT 2024


On Mon, Jul 29, 2024 at 03:41:49PM +0100, Dave Martin wrote:
> The table tracking space usage in sigcontext.__reserved[] has got
> a bit out of date.
> 
> Update it, and clarify the opt-in constraints.
> 
> Note, svl <= 64 would be a sufficient condition for keeping the
> sve_context within range when in streaming SVE mode under SME, but
> then za_context gets too big and userspace loses anyway.  To keep
> the conditions simple, just write "svl <= 32" everywhere.
> 
> No functional change.
> 
> Signed-off-by: Dave Martin <Dave.Martin at arm.com>
> 
> ---
> 
> Note, this is a back-of-the-envelope calculation... but whatever way I
> slice it, __reserved[] looks pretty much full (!)
> 
> If Mark in particular can double-check the SME impact, that would be
> appreciated.
> 
> New arch features with a non-trivial amount of state that needs to be
> saved may need to be disabled by default and require explicitly turning
> on by a syscall unless we want to allow some ABI breakage (x86's
> experience suggests that the world takes a long time to explode when
> signal frames outgrow their official size, though).
> 
> Either way, do we need a new strategy to slow down the filling of the
> remaining space?  There is continuing demand on it (see e.g., [1]).
> 
> Migration note: at least glibc since version 2.34 [2] has stopped
> offering compile-time constant signal stack size #defines to programs
> built with -D_GNU_SOURCE. [3]  This should mitigate ABI breaks for
> programs that bother to size stacks correctly.
> 
> I haven't checked what other libcs and runtimes are doing.
> 
> Additional SME note: since userspace can freely switch in and out of
> streaming SVE mode and freely enable/disable ZA and ZT0, I'm assuming
> that none of sve_context, za_context and zt_context are mutually
> exclusive, but please shout if I have confused myself here.
> 
> [1] [PATCH v4 18/29] arm64: add POE signal support
> https://lore.kernel.org/linux-arm-kernel/20240503130147.1154804-19-joey.gouly@arm.com/
> 
> [2] [glibc] glibc-2.34
> https://sourceware.org/git/?p=glibc.git;a=tag;h=9df03063320651bc629fa427eef3ac73fabb61ba
> 
> [3] [glibc] sysconf: Add _SC_MINSIGSTKSZ/_SC_SIGSTKSZ [BZ #20305]
> https://sourceware.org/git/?p=glibc.git;a=commit;f=sysdeps/unix/sysv/linux/bits/sigstksz.h;h=6c57d320484988e87e446e2e60ce42816bf51d53
> ---
>  arch/arm64/include/uapi/asm/sigcontext.h | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/include/uapi/asm/sigcontext.h b/arch/arm64/include/uapi/asm/sigcontext.h
> index 8a45b7a411e0..2cd60fd64e9a 100644
> --- a/arch/arm64/include/uapi/asm/sigcontext.h
> +++ b/arch/arm64/include/uapi/asm/sigcontext.h
> @@ -44,11 +44,18 @@ struct sigcontext {
>   *
>   *	0x210		fpsimd_context
>   *	 0x10		esr_context
> - *	0x8a0		sve_context (vl <= 64) (optional)
> + *	0x8a0		sve_context (vl <= 64 && svl <= 32) (optional)
> + *	 0x10		tpidr2_context (optional)
> + *	0x410		za_context (svl <= 32) (optional)
> + *	 0x50		zt_context (optional)
> + *	 0x10		fpmr_context (optional)
>   *	 0x20		extra_context (optional)
>   *	 0x10		terminator (null _aarch64_ctx)
>   *
> - *	0x510		(reserved for future allocation)
> + *	 0x90		(reserved for future allocation)
> + *
> + * where vl is the non-streaming SVE vector length, as set with PR_SVE_SET_VL,
> + * and svl is the streaming SVE vector length, as set with PR_SME_SET_VL.

These are quite fiddly to check by hand, but the ones I *did* check
appear to be correct. The discussion with Mark seems tangential to the
actual diff, so I'm inclined to apply this if nobody objects.

Will



More information about the linux-arm-kernel mailing list