From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6510
Path: news.gmane.org!not-for-mail
From: Rich Felker <dalias@libc.org>
Newsgroups: gmane.linux.lib.musl.general
Subject: Re: Possible bug: MINSIGSTKSZ values
Date: Sat, 15 Nov 2014 15:56:30 -0500
Message-ID: <20141115205630.GP22465@brightrain.aerifal.cx>
References: <20141115031843.GA3679@brightrain.aerifal.cx>
Reply-To: musl@lists.openwall.com
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: ger.gmane.org 1416085016 8473 80.91.229.3 (15 Nov 2014 20:56:56 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Sat, 15 Nov 2014 20:56:56 +0000 (UTC)
To: musl@lists.openwall.com
Original-X-From: musl-return-6523-gllmg-musl=m.gmane.org@lists.openwall.com Sat Nov 15 21:56:49 2014
Return-path: <musl-return-6523-gllmg-musl=m.gmane.org@lists.openwall.com>
Envelope-to: gllmg-musl@m.gmane.org
Original-Received: from mother.openwall.net ([195.42.179.200])
	by plane.gmane.org with smtp (Exim 4.69)
	(envelope-from <musl-return-6523-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1XpkOk-00068E-Az
	for gllmg-musl@m.gmane.org; Sat, 15 Nov 2014 21:56:46 +0100
Original-Received: (qmail 4079 invoked by uid 550); 15 Nov 2014 20:56:43 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
Original-Received: (qmail 4070 invoked from network); 15 Nov 2014 20:56:42 -0000
Content-Disposition: inline
In-Reply-To: <20141115031843.GA3679@brightrain.aerifal.cx>
User-Agent: Mutt/1.5.21 (2010-09-15)
Original-Sender: Rich Felker <dalias@aerifal.cx>
Xref: news.gmane.org gmane.linux.lib.musl.general:6510
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/6510>

On Fri, Nov 14, 2014 at 10:18:43PM -0500, Rich Felker wrote:
> Note that the min pthread stack size is also well below the size of
> ucontext_t for many archs, but I don't think this is a problem. If you
> make a thread with a stack smaller than MINSIGSTKSZ+epsilon, you just
> need to start it with all signals blocked and leave them blocked (or
> avoid using signal handlers at all).

Sadly, this logic seems incorrect since we depend on signals for
cancellation. So the minimum allowable thread stack size might also be
forced higher on archs that need large signal frames... :(

Rich