[PATCH v2 0/3] System-wide tunables

[PATCH v2 0/3] System-wide tunables

[DJ Delorie]

This patch series is the initial implementation of system-wide
tunables, which I mentioned a few months ago.

The first part has ldconfig read tunable information from
/etc/tunables.conf and store it to /etc/ld.so.cache.  Reusing ldconfig
means no new documentation or training would be required of sysadmins,
or reprogramming of distro packaging.

The second part optimizes the loading of /etc/ld.so.cache and allows
for it to be loaded independently of searching for libraries.

The third part applies the stored tunable information to the running
application.

Changes since v1: fixed format bug in error() and rebased.  No other
  changes.

DJ Delorie (3):
  Add system-wide tunables: ldconfig part
  Add system-wide tunables: cache ld.so.cache
  Add system-wide tunables: Apply tunables part

 elf/Makefile               |   1 +
 elf/cache.c                |  65 +++++-
 elf/dl-cache.c             | 276 +++++++++++++++++--------
 elf/dl-tunables.c          |  85 ++++++++
 elf/ldconfig.c             |  21 +-
 elf/tunconf.c              | 408 +++++++++++++++++++++++++++++++++++++
 elf/tunconf.h              |  43 ++++
 sysdeps/generic/dl-cache.h |   6 +
 sysdeps/generic/ldconfig.h |   2 +
 9 files changed, 818 insertions(+), 89 deletions(-)
 create mode 100644 elf/tunconf.c
 create mode 100644 elf/tunconf.h

-- 
2.39.3

Re: [PATCH v2 0/3] System-wide tunables

[Szabolcs Nagy]

The 04/18/2024 23:48, DJ Delorie wrote:
> This patch series is the initial implementation of system-wide
> tunables, which I mentioned a few months ago.
> 
> The first part has ldconfig read tunable information from
> /etc/tunables.conf and store it to /etc/ld.so.cache.  Reusing ldconfig
> means no new documentation or training would be required of sysadmins,
> or reprogramming of distro packaging.

a user may want multiple glibcs with different abi
on the same system (32bit, ilp32, lp64, l64p128, ..)
all sharing the same /etc/ld.so.cache (iirc this is
possible now)

tunables can differ across targets, so they need to
be checked not to cause trouble (e.g. doing a hwcap
mask specified by an int instead of arch feature can
do different things across abis)

and i'm not sure it's a good idea that one glibc cannot
be independently updated from others since tunables are
not abi stable, while iirc the /etc/ld.so.chace is
backward compat.

Re: [PATCH v2 0/3] System-wide tunables

[DJ Delorie]

Szabolcs Nagy <szabolcs.nagy@arm.com> writes:
> tunables can differ across targets, so they need to be checked not to
> cause trouble (e.g. doing a hwcap mask specified by an int instead of
> arch feature can do different things across abis)

This is no different than setting an environment variable today, right?
The data stored in ld.so.cache has pre-computed IDs but also the string
names, and the IDs are validated and recomputed in case libc.so changes.
The value string is not parsed unless it's a generic "double" type, and
even then, the string value is still included.

I have not yet implemented any filters for the tunables, but it's
already been requested to have an only/exclude filter for "per program
image name".  I suppose I could add a filter for only/exclude hwcaps
too.

Hmm... aren't tunables processed in ld.so, not libc.so  If so, it's
*already* more difficult to support multiple glibcs at the same time
(tunables mismatch between ld.so and libc.so), unless you have a
separate filesystem namespace, in which case you have a separate
ld.so.cache also.

Re: [PATCH v2 0/3] System-wide tunables

[Szabolcs Nagy]

The 04/19/2024 17:11, DJ Delorie wrote:
> Szabolcs Nagy <szabolcs.nagy@arm.com> writes:
> > tunables can differ across targets, so they need to be checked not to
> > cause trouble (e.g. doing a hwcap mask specified by an int instead of
> > arch feature can do different things across abis)
> 
> This is no different than setting an environment variable today, right?
> The data stored in ld.so.cache has pre-computed IDs but also the string
> names, and the IDs are validated and recomputed in case libc.so changes.
> The value string is not parsed unless it's a generic "double" type, and
> even then, the string value is still included.
> 
> I have not yet implemented any filters for the tunables, but it's
> already been requested to have an only/exclude filter for "per program
> image name".  I suppose I could add a filter for only/exclude hwcaps
> too.
> 
> Hmm... aren't tunables processed in ld.so, not libc.so  If so, it's
> *already* more difficult to support multiple glibcs at the same time
> (tunables mismatch between ld.so and libc.so), unless you have a
> separate filesystem namespace, in which case you have a separate
> ld.so.cache also.

ld.so has different name across abis exactly so you
can have a filesystem with binaries for multiple abis.

(i think with qemu-user and binfmt settings you can
even run cross arch binaries on the same system,
and e.g. debian supports this via multi-arch paths.
but even plain old multi-lib can deal with 64bit vs
32bit abi)

shared ld.so.cache and ld.so.conf is imo bad design,
but if we double down on that then yes we will need
per arch filters for settings.

Re: [PATCH v2 0/3] System-wide tunables

[Adhemerval Zanella Netto]

On 22/04/24 05:47, Szabolcs Nagy wrote:
> The 04/19/2024 17:11, DJ Delorie wrote:
>> Szabolcs Nagy <szabolcs.nagy@arm.com> writes:
>>> tunables can differ across targets, so they need to be checked not to
>>> cause trouble (e.g. doing a hwcap mask specified by an int instead of
>>> arch feature can do different things across abis)
>>
>> This is no different than setting an environment variable today, right?
>> The data stored in ld.so.cache has pre-computed IDs but also the string
>> names, and the IDs are validated and recomputed in case libc.so changes.
>> The value string is not parsed unless it's a generic "double" type, and
>> even then, the string value is still included.
>>
>> I have not yet implemented any filters for the tunables, but it's
>> already been requested to have an only/exclude filter for "per program
>> image name".  I suppose I could add a filter for only/exclude hwcaps
>> too.
>>
>> Hmm... aren't tunables processed in ld.so, not libc.so  If so, it's
>> *already* more difficult to support multiple glibcs at the same time
>> (tunables mismatch between ld.so and libc.so), unless you have a
>> separate filesystem namespace, in which case you have a separate
>> ld.so.cache also.
> 
> ld.so has different name across abis exactly so you
> can have a filesystem with binaries for multiple abis.
> 
> (i think with qemu-user and binfmt settings you can
> even run cross arch binaries on the same system,
> and e.g. debian supports this via multi-arch paths.
> but even plain old multi-lib can deal with 64bit vs
> 32bit abi)
> 
> shared ld.so.cache and ld.so.conf is imo bad design,
> but if we double down on that then yes we will need
> per arch filters for settings.

I think it makes sense to add arch-specific tunables on same system,
even though this kind of deployment in not that usual as before (maybe
on some debian-like system with qemu-user).

The dl-tunable-list.h is already arch-specific, meaning that the 
environment parsing code will ignore unknown/invalid tunable.  So 
for system-wide configuration, I would expect that ldconfig to ignore
such entries (possible with an warning) and only add on the cache
valid tunables.

Re: [PATCH v2 0/3] System-wide tunables

[DJ Delorie]

Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> writes:
> I think it makes sense to add arch-specific tunables on same system,
> even though this kind of deployment in not that usual as before (maybe
> on some debian-like system with qemu-user).

Would it make sense to add per-arch filters to the tunables themselves?
So that setting a tunable via GLIBC_TUNABLES can be arch-specific as
well?

I.e.

GLIBC_TUNABLES=glibc.malloc.check@x86-64=3

with other punctuation adding other filters, like !progname or :uid

ld.so.cache uses the file itself as an arch filter, there's nothing in
the cache that indicates arch (just hwcaps and abi), so using the name
itself as an arch filter would be consistent.

> The dl-tunable-list.h is already arch-specific, meaning that the 
> environment parsing code will ignore unknown/invalid tunable.  So 
> for system-wide configuration, I would expect that ldconfig to ignore
> such entries (possible with an warning) and only add on the cache
> valid tunables.

Currently it stores them as-is, but without a valid tunable ID.  That
forces the program to re-parse the tunable, so that the cache and the
program need not be in sync.