This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2] Set default stack size from program environment
- From: Andreas Jaeger <aj at suse dot com>
- To: libc-alpha at sourceware dot org
- Date: Tue, 05 Mar 2013 15:17:36 +0100
- Subject: Re: [PATCH 1/2] Set default stack size from program environment
- References: <20130115100110.GL7894@spoyarek.pnq.redhat.com> <20130117000752.EFE8D2C0BC@topped-with-meat.com> <20130117014821.GX7894@spoyarek.pnq.redhat.com> <mvm1udk5iul.fsf@hawking.suse.de> <20130117082311.GB25252@spoyarek.pnq.redhat.com> <mvmwqvc43jy.fsf@hawking.suse.de> <20130117083500.GC25252@spoyarek.pnq.redhat.com> <mvm4nig2o6p.fsf@hawking.suse.de> <20130301210246.F2EB82C0B3@topped-with-meat.com> <CAAHN_R3=ohEZTRQ=PsD=2-eXOM_y8ZU_O3XZWsWH6VYT1wZBKg@mail.gmail.com>
On 03/05/2013 02:57 PM, Siddhesh Poyarekar wrote:
On 2 March 2013 02:32, Roland McGrath <roland@hack.frob.com> wrote:
It's worse in some regards and better in others. Anything overly
coarse-grained like system-wide configuration when it can be local
per-user or per-process/inherited configuration is worse for the
issues of user choice and flexibility. Conversely, anything only
changeable by privileged administrator action rather than inherited
from something casually fungible like the environment is better for
the issue of security hardening.
Sorry for chiming in late.
How about something like this:
1. A /etc/pthreads.conf with hard limits for stack sizes. Its absence
means that RLIMIT_STACK is in play
2. A per-user .pthreads.conf with user-level overrides for stack sizes
(default_stack_size=1024K) and/or program-level overrides
(default_stack_size=/usr/bin/foo:2M)
3. An environment variable for process-level overrides.
This would need also a clear semantic: What if both 2 and 3 are used?
That way we include stuff that everyone hates; the magic environment
variable that you hate and the configuration files that Carlos hates
and of course, slower start-up time which I'm sure *everyone* will
hate ;) However, it would IMO do a better job of providing
administrative-level adjustment of stack sizes that I attempted
before.
And doing all of that together is the most flexible way - but it means
IMHO we have not understood the problem fully.
It's either 2 or 3 - but there should not be two ways for a single user
to specify the value.
Regarding 1: Doesn't ulimit allow hard limits for stack sizes already?
This kind of different values will be very hard to debug - unless you
add also some kind of LD_DEBUG=pthread debugging facility that displays
the values read and the choice made.
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126