Re: Consensus on allowing tunables to use GLIBC_* namespace env vars.

[Siddhesh Poyarekar <siddhesh 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