Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: Dave Martin <Dave.Martin@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Mark Brown <broonie@kernel.org>, Joey Gouly <joey.gouly@arm.com>
Subject: Re: [PATCH] arm64: signal: Update sigcontext reservations table
Date: Tue, 20 Aug 2024 14:37:40 +0100	[thread overview]
Message-ID: <20240820133739.GA28338@willie-the-truck> (raw)
In-Reply-To: <20240729144149.249096-1-Dave.Martin@arm.com>

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


  parent reply	other threads:[~2024-08-20 13:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-29 14:41 [PATCH] arm64: signal: Update sigcontext reservations table Dave Martin
2024-07-29 14:53 ` Mark Brown
2024-07-29 15:51   ` Dave Martin
2024-07-29 17:01     ` Mark Brown
2024-07-30 12:51       ` Dave Martin
2024-07-30 13:22         ` Mark Brown
2024-07-30 15:07           ` Dave Martin
2024-07-30 16:00             ` Mark Brown
2024-07-31 10:38               ` Dave Martin
2024-07-31 11:49                 ` Mark Brown
2024-07-31 14:38                   ` Dave Martin
2024-07-31 14:58                     ` Mark Brown
2024-07-31 16:09                       ` Dave Martin
2024-07-31 16:14                         ` Mark Brown
2024-07-31 16:23                           ` Dave Martin
2024-08-20 13:37 ` Will Deacon [this message]
2024-08-20 14:38   ` Dave Martin
2024-08-23 11:46     ` Will Deacon
2024-09-03 14:18       ` Dave Martin
2024-09-03 18:26         ` Mark Brown
2024-09-04 11:24           ` Dave Martin
2024-09-04 11:49             ` Mark Brown
2024-09-05 10:59               ` Dave Martin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240820133739.GA28338@willie-the-truck \
    --to=will@kernel.org \
    --cc=Dave.Martin@arm.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=joey.gouly@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox