From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14401 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] Fix the use of sigaltstack to return to the saved main stack. Date: Fri, 12 Jul 2019 12:06:56 -0400 Message-ID: <20190712160656.GD1506@brightrain.aerifal.cx> References: <20190709193004.GQ1506@brightrain.aerifal.cx> <20190710183931.GT1506@brightrain.aerifal.cx> <20190710212319.GM21055@port70.net> <87h87r391i.fsf@oldenburg2.str.redhat.com> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="148259"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14417-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jul 12 18:07:17 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hly4n-000cIy-S6 for gllmg-musl@m.gmane.org; Fri, 12 Jul 2019 18:07:13 +0200 Original-Received: (qmail 20334 invoked by uid 550); 12 Jul 2019 16:07:11 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 20309 invoked from network); 12 Jul 2019 16:07:10 -0000 Content-Disposition: inline In-Reply-To: <87h87r391i.fsf@oldenburg2.str.redhat.com> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14401 Archived-At: 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