This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Consensus on allowing tunables to use GLIBC_* namespace env vars.
- From: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 10 Sep 2015 13:40:48 -0400 (EDT)
- Subject: Re: Consensus on allowing tunables to use GLIBC_* namespace env vars.
- Authentication-results: sourceware.org; auth=none
- References: <55E90AA9 dot 30909 at redhat dot com> <55F0225B dot 7060502 at redhat dot com>
----- Original Message -----
> Environment variables affect process trees, and can only be set at
> process start time. Is this really the behavior we want? The advantage
> is that it's not system-wide, but that's the disadvantage as well.
That is in fact the behaviour we want for now, a per-process method to tune
program behaviour. Inheritance of the behaviour currently exists since the
current tunables replace environment variables, so that won't be anything
new.
> The presence of environment variables changes stack alignment and where
> cache line boundaries fall on the stack. For performance tunables, this
> can be problematic because the effect from setting the environment
> variable itself can easily outrank the impact of the actual tuning change:
I believe this will happen regardless of whether we use a singled envvar or
multiple envvars because the space required for that data will be more or
less the same. For performance tunables, the recommended method for
measurement in such a scenario would be to keep the tunable defined and
change the value to determine which value is better, i.e. explicitly specify
even the default value so that it produces a similar stack alignment.
> LD_* might benefit from some existing security filters. Maybe that's
> sufficient for staying within that namespace?
I don't understand, could you please rephrase? LD_* already has some
security filters in place, i.e. a lot of them are scrubbed away for setuid
binaries. Are you suggesting doing similar for GLIBC_* variables too? I
don't see why not.
Siddhesh