commit 54ca6779 inadvertently
introduced bitwise and where logical and was intended. since the
right-hand operand is always 0 or -1 whenever the left-hand operand is
nonzero, the behavior happened to be equivalent.

priority inheritance is a feature to mitigate priority inversion
situations, where a execution of a medium-priority thread can
unboundedly block forward progress of a high-priority thread when a
lock it needs is held by a low-priority thread.

the natural way to do priority inheritance would be with a simple
futex flag to donate the calling thread's priority to a target thread
while it waits on the futex. unfortunately, linux does not offer such
an interface, but instead insists on implementing the whole locking
protocol in kernelspace with special futex commands that exist solely
for the purpose of doing PI mutexes. this would require the entire
"trylock" logic to be duplicated in the timedlock code path for PI
mutexes, since, once the previous lock holder releases the lock and
the futex call returns, the lock is already held by the caller.
obviously such code duplication is undesirable.

instead, I've made the PI timedlock success path set the mutex lock
count to -1, which can be thought of as "not yet complete", since a
lock count of 0 is "locked, with no recursive references". a simple
branch in a non-hot path of pthread_mutex_trylock can then see and act
on this state, skipping past the code that would check and take the
lock to the same code path that runs after the lock is obtained for a
non-PI mutex.

because we're forced to let the kernel perform the actual lock and
unlock operations whenever the mutex is contended, we have to patch
things up when it does the wrong thing:

1. the lock operation is not aware of whether the mutex is
   error-checking, so it will always fail with EDEADLK rather than
   deadlocking.

2. the lock operation is not aware of whether the mutex is robust, so
   it will successfully obtain mutexes in the owner-died state even if
   they're non-robust, whereas this operation should deadlock.

3. the unlock operation always sets the lock value to zero, whereas
   for robust mutexes, we want to set it to a special value indicating
   that the mutex obtained after its owner died was unlocked without
   marking it consistent, so that future operations all fail with
   ENOTRECOVERABLE.

the first of these is easy to solve, just by performing a futex wait
on a dummy futex address to simulate deadlock or ETIMEDOUT as
appropriate. but problems 2 and 3 interact in a nasty way. to solve
problem 2, we need to back out the spurious success. but if waiters
are present -- which we can't just ignore, because even if we don't
want to wake them, the calling thread is incorrectly inheriting their
priorities -- this requires using the kernel's unlock operation, which
will zero the lock value, thereby losing the "owner died with lock
held" state.

to solve these problems, we overload the mutex's waiters field, which
is unused for PI mutexes since they don't call the normal futex wait
functions, as an indicator that the PI mutex is permanently
non-lockable. originally I wanted to use the count field, but there is
one code path that needs to access this flag without synchronization:
trylock's CAS failure path needs to be able to decide whether to fail
with EBUSY or ENOTRECOVERABLE, the waiters field is already treated as
a relaxed-order atomic in our memory model, so this works out nicely.

there was no point in masking off the pshared bit when first loading
the type, since every subsequent access involves a mask anyway. not
masking it may avoid a subsequent load to check the pshared flag, and
it's just simpler.

commit 84d061d5 wrongly moved the
access to the global next_key outside of the scope of the lock. the
error manifested as spurious failure to find an available key slot
under concurrent calls to pthread_key_create, since the stopping
condition could be met after only a small number of slots were
examined.

commit d6c855ca caused this
"regression", though the behavior was undefined before, overlooking
that f->shend=0 was being used as a sentinel for "EOF" status (actual
EOF or hitting the scanf field width) of the stream helper (shgetc)
functions.

obviously the shgetc macro could be adjusted to check for a null
pointer in addition to the != comparison, but it's the hot path, and
adding extra code/branches to it begins to defeat the purpose.

so instead of setting shend to a null pointer to block further reads,
which no longer works, set it to the current position (rpos). this
makes the shgetc macro work with no change, but it breaks shunget,
which can no longer look at the value of shend to determine whether to
back up. Szabolcs Nagy suggested a solution which I'm using here:
setting shlim to a negative value is inexpensive to test at shunget
time, and automatically re-trips the cnt>=shlim stop condition in
__shgetc no matter what the original limit was.

commit 2de29bc9 left behind one
reference to pthread_mutex_trylock. fixing this also improves code
generation due to the namespace-safe version being hidde.

HWCAP_SB - speculation barrier instruction available added in linux
commit bd4fb6d270bc423a9a4098108784f7f9254c4e6d
HWCAP_PACA, HWCAP_PACG - pointer authentication instructions available
(address and generic) added in linux commit
7503197562567b57ec14feb3a9d5400ebc56812f

aarch64 pointer authentication code related prctl that allows
reinitializing the key for the thread, added in linux commit
ba830885656414101b2f8ca88786524d4bb5e8c1

NT_MIPS_MSA for ptrace access to mips simd arch reg set, added in linux
commit 3cd640832894b85b5929d5bda74505452c800421
NT_ARM_PAC_MASK for ptrace access to pointer auth code mask, added in
commit ec6e822d1a22d0eef1d1fa260dff751dba9a4258

C-SKY support was added to binutils 2.32 in commit
b8891f8d622a31306062065813fc278d8a94fe21
the elf.h change was added to glibc 2.29 in commit
4975f0c3d0131fdf697be0b1631c265e5fd39088

added in linux commit 4e21565b7fd4d9045765f697887e74a704135fe2

smoothed RTT for SCM_TIMESTAMPING_OPT_STATS control messages.
added in linux commit e8bd8fca6773ef49390269bd467bf940a0841ccf

sockopt to enable gro for udp.
added in linux commit e20cf8d3f1f763ad28a9cb3b41305b8a8a42653e

added in linux commit 5521eb4bca2db733952f068c37bdf3cd656ad23c

for armv8.5 speculative store bypass PSTATE bit support,
added in linux commit d71be2b6c0e19180b5f80a6d42039cc074a693a2

ISO7816 smart cards ioctls.
linux commit ad8c0eaa0a418ae8ef3f9217638bb86439399eac

the actual kernel definitions are

 #define TIOCGISO7816 _IOR('T', 0x42, struct serial_iso7816)
 #define TIOCSISO7816 _IOWR('T', 0x43, struct serial_iso7816)

where struct serial_iso7816 is defined in linux/serial.h as

struct serial_iso7816 {
	__u32   flags;
	__u32   tg;
	__u32   sc_fi;
	__u32   sc_di;
	__u32   clk;
	__u32   reserved[5];
};

prctls to allow per task control of indirect branch speculation on x86.

added in linux commit 9137bb27e60e554dab694eafa4cca241fa3a694f

ipv6 analogue of IP_MULTICAST_ALL sockopt.

added in linux commit 15033f0457dca569b284bef0c8d3ad55fb37eacb

new in linux commit fa788d986a3aac5069378ed04697bd06f83d3488

aarch64 supports 32MB and 512MB hugetlb page sizes too.
added in linux commit 20916d4636a9b3c1bf562b305f91d126771edaf9

wired up in linux commit 73aeb2cbcdc9be391b3d32a55319a59ce425426f

added in linux commit db7a2d1809a5b6b08d138ff68837f805fc073351

NT_MIPS_FP_MODE is new in linux commit
1ae22a0e35636efceab83728ba30b013df761592

NT_MIPS_DSP is new in linux commit
44109c60176ae73924a42a6bef64ef151aba9095

used for optimizing the rxrpc protocol
added in linux commit 5271953cad31b97dea80f848c16e96ad66401199

new fields for RFC 4898 tcp stats in linux
tcpi_bytes_sent added in commit ba113c3aa79a7f941ac162d05a3620bdc985c58d
tcpi_bytes_retrans added in commit fb31c9b9f6c85b1bad569ecedbde78d9e37cd87b
tcpi_dsack_dups added in commit 7e10b6554ff2ce7f86d5d3eec3af5db8db482caa
tcpi_reord_seen added in commit 7ec65372ca534217b53fd208500cf7aac223a383

The new fields change the size of a public struct and thus an ABI break,
but this is how the getsockopt TCP_INFO api is designed: the tcp_info
type must only be used with a length parameter in extern interfaces.

inotify_add_watch flag to prevent modifying existing watch descriptors,
when used on an already watched inode it fails with EEXIST.
added in linux commit 4d97f7d53da7dc830dbf416a3d2a6778d267ae68

added in linux commit 80b14dee2bea128928537d61c333f24cb8cbb62f

The original logic considered each byte until it either found a 0
value or a value >= 192. This means if a string segment contained any
byte >= 192 it was interepretted as a compressed segment marker even
if it wasn't in a position where it should be interpretted as such.

The fix is to adjust dn_skipname to increment by each segments size
rather than look at each character. This avoids misinterpretting
string segment characters by not considering those bytes.

On s390x, POSIX_FADV_DONTNEED and POSIX_FADV_NOREUSE have different
values than on all other architectures that Linux supports.

Handle this difference by wrapping their definitions in
include/fcntl.h in #ifdef, so that arch/s390x/bits/fcntl.h can
override them.

as noted in Austin Group issue #1236, the XSI shading for TSVTX is
misplaced in the html version of the standard; it was only supposed to
be on the description text. the intent was that the definition always
be visible, which is reflected in the pdf version of the standard.

this reverts commits d93c0740 and
729fef0a.

POSIX requires setvbuf to return non-zero if `mode` is not one of _IONBF,
_IOLBF, or _IOFBF.

C11 removed the requirement that FILE be a complete type, which was
deemed erroneous, as part of the changes introduced by N1439 regarding
completeness of types (see footnote 6 for specific mention of FILE).
however the current version of POSIX is still based on C99 and
incorporates the old requirement that FILE be a complete type.

expose an arbitrary, useless complete type definition because the
actual object used to represent FILE streams cannot be public/ABI.

thanks to commit 13d1afa4, we now have
a framework for suppressing the public complete-type definition of FILE
when stdio.h is included internally, so that a different internal
definition can be provided. this is perfectly well-defined, since the
same struct tag can refer to different types in different translation
units. it would be a problem if the implementation were accessing the
application's FILE objects or vice versa, but either would be
undefined behavior.

this affected the error path where dlopen successfully found and
loaded the requested dso and all its dependencies, but failed to
resolve one or more relocations, causing the operation to fail after
storage for the ctor queue was allocated.

commit 188759bb wrongly put the free
for the ctor_queue array in the error path inside a loop over each
loaded dso that needed to be backed-out, rather than just doing it
once. in addition, the exit path also observed the ctor_queue pointer
still being nonzero, and would attempt to call ctors on the backed-out
dsos unless the double-free crashed the process first.

historically, and likely accidentally, sigaltstack was specified to
fail with EINVAL if any flag bit other than SS_DISABLE was set. the
resolution of Austin Group issue 1187 fixes this so that the
requirement is only to fail for SS_ONSTACK (which cannot be set) or
"invalid" flags.

Linux fails on the kernel side for invalid flags, but historically
accepts SS_ONSTACK as a no-op, so it needs to be rejected in userspace
still.

with this change, the Linux-specific SS_AUTODISARM, provided since
commit 9680e1d0 but unusable due to
rejection at runtime, is now usable.

together with the previous two commits, this completes restoration of
the property that dynamic-linked apps with no external deps and no tls
have no failure paths before entry.

neither has or can have any dependencies, but since commit
40355569, gratuitous zero-length deps
arrays were being allocated for them. use a dummy array instead.

traditionally, we've provided a guarantee that dynamic-linked
applications with no external dependencies (nothing but libc) and no
thread-local storage have no failure paths before the entry point.
normally, thanks to reclaim_gaps, such a malloc will not require a
syscall anyway, but if segment alignment is unlucky, it might. use a
builtin array for this common special case.

in the case where malloc is being replaced, it's not valid to call
malloc between final relocations and main app's crt1 entry point; on
fdpic archs the main app's entry point will not yet have performed the
self-fixups necessary to call its code.

to fix, reorder queue_ctors before final relocations. an alternative
solution would be doing the allocation from __libc_start_init, after
the entry point but before any ctors run. this is less desirable,
since it would leave a call to malloc that might be provided by the
application happening at startup when doing so can be easily avoided.