From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2123 Path: news.gmane.org!not-for-mail From: boris brezillon Newsgroups: gmane.linux.lib.musl.general Subject: Re: TLS (thread-local storage) support Date: Wed, 17 Oct 2012 02:08:11 +0200 Message-ID: References: <20121004211332.GA12874@brightrain.aerifal.cx> <20121004223631.GL254@brightrain.aerifal.cx> <20121016225438.GT254@brightrain.aerifal.cx> <20121016234825.GV254@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1350432505 8995 80.91.229.3 (17 Oct 2012 00:08:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Oct 2012 00:08:25 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2124-gllmg-musl=m.gmane.org@lists.openwall.com Wed Oct 17 02:08:33 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1TOHBX-0008KP-8I for gllmg-musl@plane.gmane.org; Wed, 17 Oct 2012 02:08:31 +0200 Original-Received: (qmail 14304 invoked by uid 550); 17 Oct 2012 00:08:24 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 14296 invoked from network); 17 Oct 2012 00:08:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ONTSzyJ6vl2KbJ3TRjLXrAMulRw0fLgVEoLqKQi029U=; b=x73k+4KypVxz4YyyKAbPGmdtzFYRJ6eeYQKtBPJHO1MCHqQmGGBifLUne8xJAyfRAA GsluWwL54f3a7NRAtfG/Iu+BxQKAOaKKW+jLe4fMZtys4aaKwSz0h0f5+wFbmWdWZUc3 kpednL0LsF7+qnWcNabZ4mknF2vH9Xqe5ISHngD6t3haRErD0m99RAXuGVF6AWsd00CM 3HuG+VQglcsasDa7HuIcGjUO8e9/+8072xniMqajOE+kq1FEDmIexi+IdUzNaB7SF64X QksK/zJWfcVs1PDGVAK1RNrHodYHNofx/WI61qSDMkvEI/m2SjuObu49+/7r08xXO+JI 7aRQ== In-Reply-To: <20121016234825.GV254@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:2123 Archived-At: 2012/10/17 Rich Felker : > On Wed, Oct 17, 2012 at 01:39:49AM +0200, boris brezillon wrote: >> >> 4) Compile musl with '-fsplit-stack' and add no_split_stack attribute >> >> to appropriate functions (at least all functions called before >> >> pthread_self_init because %gs or %fs register is unusable before this >> >> call). >> > >> > This is definitely not desirable, at least not by default. It hurts >> > performance, possibly a lot, and destroys async-signal-safety. Also I >> > doubt it's needed. As long as split stack mode leaves at least ~8k >> > when calling a new function, most if not all functions in musl should >> > run fine without needing support for enlarging the stack. >> I agree. This should be made optional. But if we don't compile libc >> with fsplit-stack (-fnosplit-stack). >> Each call to a libc func from an external func compiled with split >> stack may lead to a 64K stack chunk alloc. > > Where does this allocation take place from? There should simply be a > way to inhibit it. In the linker (gold linker). > >> >> 6) add no-split-stack note to every asm file. >> > >> > I'm against this, or any boilerplate clutter. If it's really needed, >> > it should be possible with CFLAGS (or "ASFLAGS"), rather than >> > modifying every file, and if there's no way to do it with command line >> > options, that's a bug in gas. >> Not supported in gas, already tried. > > That's frustrating.. > >> > Basically, the whole idea of split-stack is antithetical to the QoI >> > guarantees of musl. A program using split-stack can crash at any time >> > due to out-of-memory, and there is no reliable/portable way to recover >> > from this condition. It's much like the following low-quality aspects >> > of glibc and default Linux config: >> The same program may crash because of stack overflow (segfault) or >> worst : corrupt memory. > > Only if written improperly. A correctly written program has bounded > stack usage that's easily proven correct with static analysis. > Unbounded stack usage is a bug, plain and simple, because there's no > way to safely and portably handle the runtime error of running out of > memory. > >> At best the split stack provides a way to increase the thread without >> crashing the whole process. > > If you're comparing the behavior of a program with initial > thread-stack size N and no-split-stack to a program with initial > thread-stack size N that can also obtain additional stack space with > split-stack, and you don't have static bounds on your stack usage that > keep it below N, then I agree that the latter will succeed in cases > where the former crashes. On the other hand, both programs WILL CRASH > under appropriate conditions, and as such, they are both buggy > programs. > >> At worst it crash the program but never corrupt the memory. > > Memory corruption will not happen without split stack either unless > you turn off guard pages or use functions with huge stack frames > without the -fstack-check option. > >> > As such, I'm willing to add whatever inexpensive support framework is >> > needed so that people who want to use split-stack can use it, but I'm >> > very wary of invasive or costly changes to support a feature which I >> > believe is fundamentally misguided (and, for 64-bit targets, utterly >> > useless). >> >> I understand. > > Getting into it more, I think split-stack is a lot harder to support > than anybody has considered, especially if you want to still have a > POSIX conforming environment. There are all sorts of nasty cases > connected to signal handlers, async-signal-safety, > async-cancel-safety, longjmp, and thread cancellation where I know at > the very least you would need some ugly bloated hacks with unwinding > to get them right, and where I'm doubtful you even _can_ make them > 100% conforming. Getting this stuff right is highly non-trivial to > begin with, even without split-stack (and glibc doesn't really even > try) so I'm doubtful that the architects of split-stack even thought > about it before throwing their experiment out there for everybody to > use... > > Rich