Re: [PATCH 3/3] Misc: Add <sys/cstack.h> and the cstack_* family of functions

[Florian Weimer <fweimer@redhat.com>]

* Bruno Haible:

> In reply to <https://sourceware.org/pipermail/libc-alpha/2021-May/126608.html>:
>
>> These functions are expected to be used with sigaltstack and
>> coroutines.
>
> What is the added value of these functions, compared to what existing
> programs already do?
>
> I did a small survey of how a couple of single-threaded programs allocate
> their alternate stack:
>   - The majority allocate it statically.
>   - Some use malloc().
>   - Some use mmap().
>   - Some use alloca(), i.e. a portion of the already-allocated stack in
>     the program's main() function.
> The size that these programs use are:
>   - some use SIGSTKSZ,
>   - some use 16 KiB,
>   - some use 64 KiB.
>
> We know that 16 KiB is too small on some platforms, and that a static
> allocation of SIGSTKSZ bytes leads to a compilation error now.
>
> Therefore the implemented added value is:
>
>   * The ability to use SIGSTKSZ without a compilation error.

And we can more easily tweak stack allocations in glibc, perhaps using
configuration values, to get old applications working on newer hardware.
We don't quite now how an application might use SIGSTKSZ, so tweaking
that value is harder.

> Other added value that would be useful in some cases are:
>
>   * The ability to have a guard page at the stack top.
>     This is half implemented. IMO an mprotect (.., top_guard_size, PROT_NONE)
>     is missing after the __mmap call.
>
>   * The ability to have a guard page at the stack bottom.
>     This too is half implemented. IMO an mprotect (.., bottom_guard_size, PROT_NONE)
>     is missing after the __mmap call.

Sorry, this is what I fixed in version 2.

>   * A verification that the allocated size is not larger than
>     getrlimit(RLIMIT_STACK). If the system or the user has set a maximum
>     stack size of, say, 8 MB, should the program be able to allocate a
>     stack of 1 GB size, in this way?

Sure, why not?  It could be used as an escape hatch if the configured
stack size is too small.

>   * Support for GCC nested functions, when they need an executable stack.
>     GCC, binutils, and glibc/nptl/allocatestack.c go to great lengths to
>     support this, even from dynamically loaded shared libraries. (See the
>     attached test cases.) It is poor if this facility does not support it.

I can try to add this.  It's reasonably straightforward for Linux.  It
may be a little bit harder on Hurd.

>   * Automatic deallocation when the current thread exits.
>     In those cases where a thread allocated a cstack_t for its own use,
>     it is welcome if it can say "clean it up automatically when the thread
>     exits". Otherwise some programmers will still prefer the "use alloca()"
>     approach, which has this automatic cleanup property.

Do you think it's sufficient to specify this at thread creation time?
An interface that does this at a later stage may have to deal with the
case where a new alternate stack is installed while the code is running
on the alternate stack previously assigned to the current thread.

Thanks,
Florian