Re: What can a signal handler do with SIGSTKSZ?

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

On 11/01/2019 19:11, Carlos O'Donell wrote:
> On 1/11/19 2:02 PM, Szabolcs Nagy wrote:
>> On 11/01/2019 17:44, Carlos O'Donell wrote:
>>> In the continuing series of "What can X do with Y?" [1]
>>>
>>> I would like to get consensus on what a signal handler can do with
>>> SIGSTKSZ amount of space.
>>>
>>> I propose the following:
>>> ~~~
>>> The implementation only guarantees that a signal handler can
>>> manipulate a reasonable amount of local variables (no more than
>>> 2 KiB worth), and can read and write to memory, carry out atomic
>>> operations, and call simple C library functions that do similar
>>> memory and simple string operations e.g. memcpy, memset, strcmp,
>>> strcpy. The amount of signal stack allocated for SIGSTKSZ is not
>>> sufficient to call complex signal-safe functions e.g. fork, _exit,
>>> abort, nor any that can be canceled (requires enough stack for
>>> cancellation). Any other operations or function calls in the
>>> signal handler should be evaluated for runtime stack usage and
>>> additional stack beyond SIGSTKSZ should be allocated.
>>> ~~~
>>>
>>> Thoughts?
>>
>> instead of "local variables" i'd say: user
>> code may use X bytes stack space and the
>> rest is for the runtime (which is guaranteed
>> to be enough for simple libc calls,...).
>>
>> X can be 2048.
>>
>> runtime stack usage vs user stack usage can
>> be accounted based on stack usage of libc code
>> vs user code.
>  
> I was wondering if I could simplify the language and just say:
> 
> There are (SIGSTKSZ - MINSTKSZ) bytes to use upon entry to the
> first signal handler, with stack space consumption happening
> as the handler executes. Each subsequent nested signal handler
> uses an additional MINSTKSZ bytes. 
> 
> What do you think?

works for me, but

MINSIGSTKSZ can be interpreted as just enough for the
kernel to deliver the signal and call the signal handler.
(currently it's not enough on x86_64 and on aarch64 with
sve. on aarch64 there is kernel provided AT_MINSIGSTKSZ
auxv value that is enough, but really posix requires a
sysconf for this instead of a fixed macro then.)

so users should be aware that there may be additional
overheads not visible in their code (we don't wrap
signal handlers currently but might, there is lazy
binding overhead for extern calls) so not all
SIGSTKSZ - MINSIGSTKSZ is for the user: it is for
user code + runtime.