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

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 14/01/2019 09:18, Szabolcs Nagy wrote:
> 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.
> 

>From an implementation standpoint, how the lib would calculate _SC_SIGSTKSZ?
Just plus constant based on _SC_MINSIGSTKSZ? If it is the idea we might go
only with _SC_MINSIGSSTKSZ and export the value adjustment instead.