[PATCH] arm64: signal: Update sigcontext reservations table

[Mark Brown]

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.

> > > 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.
-------------- 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/20240731/445498c4/attachment.sig>