[PATCH] arm64: signal: Update sigcontext reservations table

[Dave Martin]

On Wed, Jul 31, 2024 at 12:49:39PM +0100, Mark Brown wrote:
> On Wed, Jul 31, 2024 at 11:38:55AM +0100, Dave Martin wrote:
> > On Tue, Jul 30, 2024 at 05:00:17PM +0100, Mark Brown wrote:
> 
> > > A good percentage of programs manage to just use a default rather then
> > > ever explicitly specifying or configuring anything themselves - C
> > > programs will default to RLIMIT_STACK IIRC which is system configured
> > > and generally set rather high.  It's true that anything that is
> 
> > That's all true, but even programs that don't explicity work out stack
> > sizes may be using implicit knowledge, beacuse the developers may have
> > simple bumped up stack sizes.
> 
> Sure, there will be problems in some places but poking around I'm seeing
> defaults that tend more to the generous sizes which is consistent with
> the x86 experience here.
> 
> > Note, RLIMIT_STACK only applies the initial stack of the main thread.
> > Processes with threads might have many stacks, as might processes with
> > fibers/coroutines (allocated any old how, and often with no reference
> > to RLIMIT_STACK).
> 
> It's the default for pthread_create() too - dunno about any common
> libraries for light threads, they're definitely the sort of thing where
> I'd more expect to find code that actually does anything explicit about
> the stack size.
> 
> > The aim here is to minimise surprises for code that made reasonable
> > assumptions at the time it was written, rather than to ensure that
> > every ancient binary that ever worked by accident still works, no
> > matter what crazy nonportable shenanigans it gets up to.
> 
> Indeed, my suspicion is that the problem is more limited than it might
> be - things that either look at the signal frame or not only explicitly
> configure stack sizes, but also explicitly configure small stack sizes.

Sure, it's rare, and we expect it to be rare; and defaults for stack
allocation are indeed usually fairly generous.

> > > > The idea of the table in sigcontext.h was to help us track where opt-
> > > > ins are needed, and what opt-in conditions exist.  This maybe wasn't as
> > > > clear as it could have been.
> 
> > > I think some of it is the strength of the opt ins being considered.
> 
> > Sorry, what do you mean here?
> 
> The comments in the header just mention that something chooses to use
> the extension, they don't highlight the idea that it's considering the
> worst case where some random library somewhere in an executable uses an
> extension - it's a bit vauge about what specifically is expected to be
> considered.

I guess I didn't want to over-promise re. guarantees.

This table was planted here partly as a reminder that there is a
problem coming down the tracks here that requires thinking about...


Can we refocus this discussion?

For the patch itself, can you say whether the proposed update is right
or wrong, and whether you think we need to document this better and/or
change the approach?

I'm not committed to any particular way forward, but it feels like we
shouldn't just let this ABI break sail past without making a decision
about how to manage it.

Cheers
---Dave