[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 12 Jul 2019 12:06:56 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] Fix the use of sigaltstack to return to the saved
main stack.
On Fri, Jul 12, 2019 at 11:18:49AM +0200, Florian Weimer wrote:
> * Szabolcs Nagy:
>
> > the comment does not make sense to me, the check is obviously
> > not redundant.
> >
> > MINSIGSTKSZ is a libc api, has nothing to do with the kernel
> >
> > the kernel also defines a MINSIGSZTKSZ but musl is an
> > abstraction layer higher, the linux limit should not be
> > observable to users, only the limit defined by musl,
> > which ensures not only that the kernel can deliver a
> > signal but also reserves space of any current or future
> > hackery the c runtime may need to do around signal handling,
> > so that trivial c language signal handler is guaranteed
> > to work.
>
> Please keep in mind that the kernel stack requirements for delivering a
> signal vary and tend to increase over time, with newer CPU generations
> with larger register files. It leads to bugs to pretend this value is
> constant.
If that's really going to be the position, then we need to standardize
removal of the macro as mandatory, and replacement by a sysconf. I
think that's a mistake though. Unbounded increase in register file
size destroys the potential for tolerable task-switch performance,
even for tasks in the same process that should switch very fast. My
(probably unpopular) opinion is that kernel just should not support
use of ridiculous huge register file additions like AVX512, or should
do so only for processes tagged as compatible with it (which would be
built with an ABI having a larger value of the constant).
Note that some archs like aarch64 explicitly reserved an upper bound
for future expansion, which is IMO already way too large, but at least
it's a bound.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
