Re: aio_cancel segmentation fault for in progress write requests

[Florian Weimer <fweimer@redhat.com>]

* Rich Felker:

> On Fri, Dec 07, 2018 at 09:06:18PM +0100, Florian Weimer wrote:
>> * Rich Felker:
>> 
>> > I don't think so. I'm concerned that it's a stack overflow, and that
>> > somehow the kernel folks have managed to break the MINSIGSTKSZ ABI.
>> 
>> Probably:
>> 
>>   <https://sourceware.org/bugzilla/show_bug.cgi?id=20305>
>>   <https://sourceware.org/bugzilla/show_bug.cgi?id=22636>
>> 
>> It's a nasty CPU backwards compatibility problem.  Some of the
>> suggestions I made to work around this are simply wrong; don't take them
>> too seriously.
>> 
>> Nowadays, the kernel has a way to disable the %zmm registers, but it
>> unfortunately does not reduce the save area size.
>
> How large is the saved context with the %zmm junk? I measured just
> ~768 bytes on normal x86_64 without it, and since 2048 is rounded up
> to a whole page (4096), overflow should not happen until the signal
> context is something like 3.5k (allowing ~512 bytes for TCB (~128) and
> 2 simple call frames).

I wrote a test to do some measurements:

  <https://sourceware.org/ml/libc-alpha/2018-12/msg00271.html>

The signal handler context is quite large on x86-64 with AVX-512F,
indeed around 3.5 KiB.  It is even larger on ppc64 and ppc64el
(~4.5 KiB), which I find somewhat surprising.

The cancellation test also includes stack usage from the libgcc
unwinder.  Its stack usage likely differs between versions, so I should
have included that in the reported results.

Thanks,
Florian