glibc/manual
H.J. Lu 6c57d32048 sysconf: Add _SC_MINSIGSTKSZ/_SC_SIGSTKSZ [BZ #20305]
Add _SC_MINSIGSTKSZ for the minimum signal stack size derived from
AT_MINSIGSTKSZ, which is the minimum number of bytes of free stack
space required in order to gurantee successful, non-nested handling
of a single signal whose handler is an empty function, and _SC_SIGSTKSZ
which is the suggested minimum number of bytes of stack space required
for a signal stack.

If AT_MINSIGSTKSZ isn't available, sysconf (_SC_MINSIGSTKSZ) returns
MINSIGSTKSZ.  On Linux/x86 with XSAVE, the signal frame used by kernel
is composed of the following areas and laid out as:

 ------------------------------
 | alignment padding          |
 ------------------------------
 | xsave buffer               |
 ------------------------------
 | fsave header (32-bit only) |
 ------------------------------
 | siginfo + ucontext         |
 ------------------------------

Compute AT_MINSIGSTKSZ value as size of xsave buffer + size of fsave
header (32-bit only) + size of siginfo and ucontext + alignment padding.

If _SC_SIGSTKSZ_SOURCE or _GNU_SOURCE are defined, MINSIGSTKSZ and SIGSTKSZ
are redefined as

/* Default stack size for a signal handler: sysconf (SC_SIGSTKSZ).  */
 # undef SIGSTKSZ
 # define SIGSTKSZ sysconf (_SC_SIGSTKSZ)

/* Minimum stack size for a signal handler: SIGSTKSZ.  */
 # undef MINSIGSTKSZ
 # define MINSIGSTKSZ SIGSTKSZ

Compilation will fail if the source assumes constant MINSIGSTKSZ or
SIGSTKSZ.

The reason for not simply increasing the kernel's MINSIGSTKSZ #define
(apart from the fact that it is rarely used, due to glibc's shadowing
definitions) was that userspace binaries will have baked in the old
value of the constant and may be making assumptions about it.

For example, the type (char [MINSIGSTKSZ]) changes if this #define
changes.  This could be a problem if an newly built library tries to
memcpy() or dump such an object defined by and old binary.
Bounds-checking and the stack sizes passed to things like sigaltstack()
and makecontext() could similarly go wrong.
2021-02-01 11:00:52 -08:00
..
examples Update copyright dates with scripts/update-copyrights 2021-01-02 12:17:34 -08:00
argp.texi
arith.texi
charset.texi
check-safety.sh Update copyright dates with scripts/update-copyrights 2021-01-02 12:17:34 -08:00
conf.texi sysconf: Add _SC_MINSIGSTKSZ/_SC_SIGSTKSZ [BZ #20305] 2021-02-01 11:00:52 -08:00
contrib.texi
creature.texi sysconf: Add _SC_MINSIGSTKSZ/_SC_SIGSTKSZ [BZ #20305] 2021-02-01 11:00:52 -08:00
crypt.texi
ctype.texi
debug.texi
dir
errno.texi
fdl-1.3.texi Sync FDL from https://www.gnu.org/licenses/fdl-1.3.texi 2021-01-02 12:46:25 -08:00
filesys.texi
freemanuals.texi
getopt.texi
header.texi
install-plain.texi
install.texi Update INSTALL with package versions that are known to work 2021-01-25 13:13:17 -03:00
intro.texi
io.texi
ipc.texi
job.texi
lang.texi
lgpl-2.1.texi
libc-texinfo.sh
libc.texinfo Update copyright dates with scripts/update-copyrights 2021-01-02 12:17:34 -08:00
libcbook.texi
libdl.texi
llio.texi manual: Clarify File Access Modes section and add O_PATH 2020-12-03 10:59:50 +01:00
locale.texi
macros.texi
maint.texi
Makefile Update copyright dates with scripts/update-copyrights 2021-01-02 12:17:34 -08:00
math.texi
memory.texi free: preserve errno [BZ#17924] 2020-12-29 00:46:46 -08:00
message.texi
nss.texi
nsswitch.texi
pattern.texi
pipe.texi
platform.texi <sys/platform/x86.h>: Remove the C preprocessor magic 2021-01-21 05:58:17 -08:00
probes.texi ieee754: Remove unused __sin32 and __cos32 2020-12-18 12:10:31 +05:30
process.texi
README.pretty-printers
README.tunables Reword description of SXID_* tunable properties 2020-10-22 13:52:38 +05:30
resource.texi Move vtimes to a compatibility symbol 2020-10-19 16:44:20 -03:00
search.texi
setjmp.texi
signal.texi
socket.texi
startup.texi Argument Syntax: Use "option", @option, and @command. 2020-10-30 13:08:38 -04:00
stdio-fp.c
stdio.texi
string.texi manual: replace an obsolete collation example with a valid one 2020-10-13 14:58:16 +02:00
summary.pl Update copyright dates with scripts/update-copyrights 2021-01-02 12:17:34 -08:00
sysinfo.texi manual: Correct argument order in mount examples [BZ #27207] 2021-01-22 14:22:41 -05:00
syslog.texi
terminal.texi
texinfo.tex
texis.awk
threads.texi nptl: Return EINVAL for invalid clock for pthread_clockjoin_np 2020-11-25 10:46:25 -03:00
time.texi
tsort.awk Update copyright dates with scripts/update-copyrights 2021-01-02 12:17:34 -08:00
tunables.texi ld.so: Add --list-tunables to print tunable values 2021-01-15 05:59:10 -08:00
users.texi
xtract-typefun.awk

			TUNABLE FRAMEWORK
			=================

Tunables is a feature in the GNU C Library that allows application authors and
distribution maintainers to alter the runtime library behaviour to match their
workload.

The tunable framework allows modules within glibc to register variables that
may be tweaked through an environment variable.  It aims to enforce a strict
namespace rule to bring consistency to naming of these tunable environment
variables across the project.  This document is a guide for glibc developers to
add tunables to the framework.

ADDING A NEW TUNABLE
--------------------

The TOP_NAMESPACE macro is defined by default as 'glibc'.  If distributions
intend to add their own tunables, they should do so in a different top
namespace by overriding the TOP_NAMESPACE macro for that tunable.  Downstream
implementations are discouraged from using the 'glibc' top namespace for
tunables they don't already have consensus to push upstream.

There are three steps to adding a tunable:

1. Add a tunable to the list and fully specify its properties:

For each tunable you want to add, make an entry in elf/dl-tunables.list.  The
format of the file is as follows:

TOP_NAMESPACE {
  NAMESPACE1 {
    TUNABLE1 {
      # tunable attributes, one per line
    }
    # A tunable with default attributes, i.e. string variable.
    TUNABLE2
    TUNABLE3 {
      # its attributes
    }
  }
  NAMESPACE2 {
    ...
  }
}

The list of allowed attributes are:

- type:			Data type.  Defaults to STRING.  Allowed types are:
			INT_32, UINT_64, SIZE_T and STRING.  Numeric types may
			be in octal or hexadecimal format too.

- minval:		Optional minimum acceptable value.  For a string type
			this is the minimum length of the value.

- maxval:		Optional maximum acceptable value.  For a string type
			this is the maximum length of the value.

- default:		Specify an optional default value for the tunable.

- env_alias:		An alias environment variable

- security_level:	Specify security level of the tunable for AT_SECURE
			binaries.  Valid values are:

			SXID_ERASE: (default) Do not read and do not pass on to
			child processes.
			SXID_IGNORE: Do not read, but retain for non-AT_SECURE
			child processes.
			NONE: Read all the time.

2. Use TUNABLE_GET/TUNABLE_SET/TUNABLE_SET_WITH_BOUNDS to get and set tunables.

3. OPTIONAL: If tunables in a namespace are being used multiple times within a
   specific module, set the TUNABLE_NAMESPACE macro to reduce the amount of
   typing.

GETTING AND SETTING TUNABLES
----------------------------

When the TUNABLE_NAMESPACE macro is defined, one may get tunables in that
module using the TUNABLE_GET macro as follows:

  val = TUNABLE_GET (check, int32_t, TUNABLE_CALLBACK (check_callback))

where 'check' is the tunable name, 'int32_t' is the C type of the tunable and
'check_callback' is the function to call if the tunable got initialized to a
non-default value.  The macro returns the value as type 'int32_t'.

The callback function should be defined as follows:

  void
  TUNABLE_CALLBACK (check_callback) (int32_t *valp)
  {
  ...
  }

where it can expect the tunable value to be passed in VALP.

Tunables in the module can be updated using:

  TUNABLE_SET (check, int32_t, val)

where 'check' is the tunable name, 'int32_t' is the C type of the tunable and
'val' is a value of same type.

To get and set tunables in a different namespace from that module, use the full
form of the macros as follows:

  val = TUNABLE_GET_FULL (glibc, cpu, hwcap_mask, uint64_t, NULL)

  TUNABLE_SET_FULL (glibc, cpu, hwcap_mask, uint64_t, val)

where 'glibc' is the top namespace, 'cpu' is the tunable namespace and the
remaining arguments are the same as the short form macros.

The minimum and maximum values can updated together with the tunable value
using:

  TUNABLE_SET_WITH_BOUNDS (check, int32_t, val, min, max)

where 'check' is the tunable name, 'int32_t' is the C type of the tunable,
'val' is a value of same type, 'min' and 'max' are the minimum and maximum
values of the tunable.

To set the minimum and maximum values of tunables in a different namespace
from that module, use the full form of the macros as follows:

  val = TUNABLE_GET_FULL (glibc, cpu, hwcap_mask, uint64_t, NULL)

  TUNABLE_SET_WITH_BOUNDS_FULL (glibc, cpu, hwcap_mask, uint64_t, val, min, max)

where 'glibc' is the top namespace, 'cpu' is the tunable namespace and the
remaining arguments are the same as the short form macros.

When TUNABLE_NAMESPACE is not defined in a module, TUNABLE_GET is equivalent to
TUNABLE_GET_FULL, so you will need to provide full namespace information for
both macros.  Likewise for TUNABLE_SET, TUNABLE_SET_FULL,
TUNABLE_SET_WITH_BOUNDS and TUNABLE_SET_WITH_BOUNDS_FULL.

** IMPORTANT NOTE **

The tunable list is set as read-only after the dynamic linker relocates itself,
so setting tunable values must be limited only to tunables within the dynamic
linker, that too before relocation.

FUTURE WORK
-----------

The framework currently only allows a one-time initialization of variables
through environment variables and in some cases, modification of variables via
an API call.  A future goals for this project include:

- Setting system-wide and user-wide defaults for tunables through some
  mechanism like a configuration file.

- Allow tweaking of some tunables at runtime