POSIX places an obscure requirement on popen which is like a limited
version of close-on-exec:
"The popen() function shall ensure that any streams from previous
popen() calls that remain open in the parent process are closed in
the new child process."
if the POSIX-future 'e' mode flag is passed, producing a pipe FILE
with FD_CLOEXEC on the underlying pipe, this requirement is
automatically satisfied. however, for applications which use multiple
concurrent popen pipes but don't request close-on-exec, fd leaks from
earlier popen calls to later ones could produce deadlock situations
where processes are waiting for a pipe EOF that will never happen.
to fix this, iterate through all open FILEs and add close actions for
those obtained from popen. this requires holding a lock on the open
file list across the posix_spawn call so that additional popen FILEs
are not created after the list is traversed. note that it's still
possible for another popen call to start and create its pipe while the
lock is held, but such pipes are created with O_CLOEXEC and only drop
close-on-exec status (when 'e' flag is omitted) under control of the
lock.
the newly allocated FILE * has not yet leaked to the application and
is only visible to stdio internals until popen returns. since we do
not change any fields of the structure observed by libc internals,
only the pipe_pid member, locking is not necessary.
__tls_get_addr should not be called with an invalid TLS module id of
0. in practice it probably "works", returning the DTV length as if it
were a pointer, and the callback should probably not inspect
dlpi_tls_data in this case, but it's likely that some real-world
callbacks use a check on dlpi_tls_data being non-null, rather than on
dlpi_tls_modid being nonzero, to conclude that the module has TLS.
With mallocng, calling posix_memalign() or aligned_alloc() will
SIGSEGV if the internal malloc() call returns NULL. This does not
occur with oldmalloc, which explicitly checks for allocation failure.
this is a Linux-specific function and not covered by POSIX's
requirements for which interfaces are cancellation points, but glibc
makes it one and existing software relies on it being one.
at some point a review for similar functions that should be made
cancellation points should be done.
dl_iterate_phdr was wrongly reporting the address of the DSO's PT_TLS
image rather than the calling thread's instance of the TLS. the man
page, which is essentially normative for a nonstandard function of
this sort, clearly specifies the latter. it does not clarify where
exactly within/relative-to the image the pointer should point, but the
reasonable thing to do is match the ABI's DTP offset, and this seems
to be what other implementations do.
popen was special-casing the possibility (only possible when the
parent closed stdin and/or stdout) that the child's end of the pipe
was already on the final desired fd number, in which case there was no
way to get rid of its close-on-exec flag in the child. commit
6fc6ca1a32 made this unnecessary by
implementing the POSIX-future requirement that dup2 file actions with
equal source and destination fd values remove the close-on-exec flag.
this makes it possible to perform actions on file actions objects with
a libc-internal lock held without creating lock order relationships
that are silently imposed on an application-provided malloc.
reportedly the GNU linker can emit such segments, causing spurious
failure to load due to mmap with a length of zero producing EINVAL.
no action is required for such a load map (it's effectively a nop in
the program headers table) so just treat it as always successful.
since 4.1, gcc has had the __returns_twice__ attribute and has
required functions which return twice to carry it; however it's always
applied it automatically to known setjmp-like function names. clang
however does not do this reliably, at least not with -ffreestanding
and possibly under other conditions, resulting in silent emission of
wrong code.
since the symbol name setjmp is in no way special (setjmp is specified
as a macro that could expand to use any implementation-specific symbol
name or names), a compiler is justified not to do anything special
without further hints, and it's reasonable to do what we can to
provide such hints.
gcc 4.0.x and earlier do not recognize the attribute, so make use
conditional on __GNUC__ macros. clang and other gcc-like compilers
report (and have always reported) a later "GNUC" version so the
preprocessor conditional should function as desired for them as too.
undefine the internal macro after use so that nothing abuses it as a
public feature.
add synchronouse and asynchronous tag check failure codes, see
linux commit 74f1082487feb90bbf880af14beb8e29c3030c9f
arm64: mte: Add specific SIGSEGV codes
these are for the aarch64 MTE (memory tagging extension), see
linux commit 1c101da8b971a36695319dce7a24711dc567a0dd
arm64: mte: Allow user control of the tag check mode via prctl()
linux commit af5ce95282dc99d08a27a407a02c763dde1c5558
arm64: mte: Allow user control of the generated random tags via prctl()
path resolution does not follow symlinks on nosymfollow mounts (but
readlink still does), see
linux commit dab741e0e02bd3c4f5e2e97be74b39df2523fc6e
Add a "nosymfollow" mount option.
can cause rseq restart on another cpu to synchronize with global
memory access from rseq critical sections, see
linux commit 2a36ab717e8fe678d98f81c14a0b124712719840
rseq/membarrier: Add MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ
mainly added to linux to allow a central process management service in
android to give MADV_COLD|PAGEOUT hints for other processes, see
linux commit ecb8ac8b1f146915aa6b96449b66dd48984caacc
mm/madvise: introduce process_madvise() syscall: an external memory
hinting API
the historical function was specified to return an empty string in the
caller-provided buffer, not a null pointer, to indicate error when the
argument is non-null. only when the argument is null should it return
a null pointer on error.
getpwuid_r can return 0 but without a result in the case where there
was no error but no record exists. in that case cuserid was treating
it as success and copying junk out of pw.pw_name to the output buffer.
this function was removed from the standard in 2001 but appeared in
SUSv2 with an obligation to support calls with a null pointer
argument, using a static buffer.
the threshold was wrong so expm1f overflowed to inf a bit too early
and on most targets uint32_t compare is faster than float compare so
use that.
this also fixes sinhf incorrectly returning nan for some values where
the internal expm1f overflowed.
on some negative inputs (e.g. -0x1.1e6ae8p+5) acoshf failed to return
nan. ensure that negative inputs result nan without introducing new
branches. this was tried before in
commit 101e601285
math: fix acoshf on negative values
but that fix was wrong. there are 3 formulas used:
log1p(x-1 + sqrt((x-1)*(x-1)+2*(x-1)))
log(2*x - 1/(x+sqrt(x*x-1)))
log(x) + 0.693147180559945309417232121458176568
the first fails on large negative inputs (may compute log1p(0) or
log1p(inf)), the second one fails on some mid range or large negative
inputs (may compute log(large) or log(inf)) and the last one fails on
-0 (returns -inf).
as an outcome of Austin Group issue #385, future versions of the
standard will require free not to alter the value of errno. save and
restore it individually around the calls to madvise and munmap so that
the cost is not imposed on calls to free that do not result in any
syscall.
as an outcome of Austin Group issue #385, future versions of the
standard will require free not to alter the value of errno. save and
restore it individually around the calls to madvise and munmap so that
the cost is not imposed on calls to free that do not result in any
syscall.
commit 7586360bad removed the unused
arguments from the definition of __libc_start_main, making it
incompatible with the declaration at the point of call, which still
passed 6 arguments. calls with mismatched function type have undefined
behavior, breaking LTO and any other tooling that checks for function
signature mismatch.
removing the extra arguments from the point of call (crt1) is not an
option for fixing this, since that would be a change in ABI surface
between application and libc.
adding back the extra arguments requires some care. on archs that pass
arguments on the stack or that reserve argument spill space for the
callee on the stack, it imposes an ABI requirement on the caller to
provide such space. the modern crt1.c entry point provides such space,
but originally there was arch-specific asm for the call to
__libc_start_main. the last of this asm was removed in commit
6fef8cafbd, and manual review of the
code removed and its prior history was performed to check that all
archs/variants passed the legacy init/fini/ldso_fini arguments.
these functions are specified to fail with EBADF on negative fd
arguments. apart from close, they are also specified to fail if the
value exceeds OPEN_MAX, but as written it is not clear that this
imposes any requirement when OPEN_MAX is not defined, and it's
undesirable to impose a dynamic limit (via setrlimit) here since the
limit at the time of posix_spawn may be different from the limit at
the time of setting up the file actions. this may require revisiting
later.
commit 2412638bb3 got the size of struct
v4l2_event wrong and failed to account for the fact that the old
struct might be either 120 bytes with time misaligned mod 8, or 128
bytes with time aligned mod 8, due to the contained union having
64-bit members whose alignment is arch-dependent.
rather than adding new logic to handle the differences, use an actual
stripped-down version of the structure in question to derive the ioctl
number, size, and offsets.
commit 2412638bb3 got the size of struct
v4l2_buffer wrong and omitted the tv_usec member slot from the offset
list, so the ioctl numbers never matched and fallback code path was
never taken. this caused the affected ioctls to fail with ENOTTY on
kernels not new enough to have the native time64 ioctls.
this is necessary for MT-fork correctness now that the code runs under
locale lock. it would not be hard to avoid, but __get_locale is
already using libc-internal malloc anyway. this can be reconsidered
during locale overhaul later if needed.
in general, pthread_once is not compatible with MT-fork constraints
(commit 167390f055). here it actually no
longer matters, because it's now called with a lock held, but since
the lock is held it's pointless to use pthread_once.
this allows the lock to be shared with setlocale, eliminates repeated
per-category lock/unlock in newlocale, and will allow the use of
pthread_once in newlocale to be dropped (to be done separately).
the intent here is just to scan at least l bytes forward for the end
of the haystack and at least some decent minimum to avoid doing it
over and over if the needle is short, with no need to be precise. the
comment erroneously stated this as an estimate for MIN when it's
actually an estimate for MAX.
pthread_once is not compatible with MT-fork constraints (commit
167390f055) and is not needed here
anyway; we already have a lock suitable for initialization.
while changing this, fix a corner case where AT_MINSIGSTKSZ gives a
value that's more than MINSIGSTKSZ but by a margin of less than
2048, thereby causing the size to be reduced. it shouldn't matter but
the intent was to be the larger of a 2048-byte margin over the legacy
fixed minimum stack requirement or a 512-byte margin over the minimum
the kernel reports at runtime.
this change should have been made when priority inheritance mutex
support was added. if priority protection is also added at some point
the implementation will need to change and will probably no longer be
a simple bit shuffling.
Érico Nogueira
Rich Felker
Joakim Sindholt
Dominic Chen
Szabolcs Nagy
Sören Tempel
Khem Raj
Arnd Bergmann
Ariadne Conill
Drew DeVault