On Wed, Oct 11, 2017 at 11:19:03AM +0100, Szabolcs Nagy wrote: > On 10/10/17 19:38, Dave Martin wrote: > > Stateful CPU architecture extensions may require the signal frame > > to grow to a size that exceeds the arch's MINSIGSTKSZ #define. > > However, changing this #define is an ABI break. > > > > To allow userspace the option of determining the signal frame size > > in a more forwards-compatible way, this patch adds a new auxv entry > > tagged with AT_MINSIGSTKSZ, which provides the maximum signal frame > > size that the process can observe during its lifetime. > > > > If AT_MINSIGSTKSZ is absent from the aux vector, the caller can > > assume that the MINSIGSTKSZ #define is sufficient. This allows for > > a consistent interface with older kernels that do not provide > > AT_MINSIGSTKSZ. > > > > the posix sigaltstack api shall fail with ENOMEM > if smaller than MINSIGSTKSZ stack size is used. > > so it is important to note somewhere if AT_MINSIGSTKSZ > is intended to be always >= MINSIGSTKSZ define (which > is rounded up to 5k) or it may be smaller as it provides > the precise value of the largest signal frame. > > (i think it makes sense for it to be a precise value, > but then users should do the >= check before calling > the sigaltstack api, so they should be aware of this > issue) This is a good point, and one that I don't have an answer for yet. POSIX[1] says that sigaltstack() _shall_ return EPERM if ss_size < MINSIGSTKSZ. I don't know the full rationale behind this. The ENOMEM return here doesn't guarantee that signal delivery will definitely fail or compromise safety when ss_size or less of stack is available. A 0 return doesn't guarantee that signal delivery on the registered alternate stack will succeed or be safe. So while the ENOMEM return has some sanity-check value, it's very limited in its usefulness. I currently saw no good reason to misrepresent the true signal frame size in AT_MINSIGSTKSZ, so it is currently a precise value that can be < MINSIGSTKSZ (and is, in the default case). In an ideal world, my preference would be to relax the check in sigaltstack() to check >= AT_MINSIGSTKSZ, but it is technically an ABI break... We _could_ paper over this by rounding up the AT_MINSIGSTKSZ value reported by the kernel to be always >= MINSIGSTKSZ. This seems ugly, but may be the most pragmatic option. Thoughts? Cheers ---Dave [1] SUSv7 / IEEE Std 1003.1-2008 (2016): sigaltstack http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigaltstack.html
