Re: Fwd: What can a signal handler do with SIGSTKSZ?

[Szabolcs Nagy <Szabolcs.Nagy@arm.com>]

On 11/01/2019 23:59, Zack Weinberg wrote:
> On Fri, Jan 11, 2019 at 3:29 PM Florian Weimer <fweimer@redhat.com> wrote:
>> * Zack Weinberg:
>>> Do you think we could push the kernel people to expose the space
>>> requirement of a signal frame in some fashion that we could wrap up in
>>> a new sysconf() constant?  Then we could deprecate the constants, in
>>> the same way that long ago PAGESIZE was replaced by
>>> sysconf(_SC_PAGESIZE).
>>
>> That's an interesting idea.  sigaltstack could also check that the size
>> is at least that large, but then the question is how many sigaltstack
>> users check the error return value.
> 
> Probably not very many...
> 
>> However, based on what I saw in the kernel sources, it's not that they
>> have an exact upper bound in the sources or even at run time.  I think
>> the code simply uses space as it proceeds (at least on x86).  But
>> perhaps I misread it.
> 
> Yeesh.  I think that has got to get fixed, independent of everything else.
> 
> This is not really my area of expertise, but here's what comes to mind
> for a way forward:

as far as i know aarch64 kernel calculates and reports worst
case stack frame size precisely, so that's probably just an
x86 issue.

i think proposing sysconf(_SC_{MIN}SIGSTKSZ) for posix is the
right solution with the kernel providing an upper bound of the
stack frame in AT_MINSIGSTKSZ (as it already does on aarch64).

with the current wording of the standard SIGSTKSZ and MINSIGSTKSZ
definition cannot be omitted when they are runtime variables,
so posix needs to be updated.