After commit 5b74eed3b301e2227385f3bf26d3bb7c2d822cf8 the timer thread doesn't check whether timer_create() actually created the timer, proceeding to wait for a signal that might never arrive. We can't fix this by simply checking for a negative timer_id after pthread_barrier_wait() because we have no way to distinguish a timer creation failure and a request to delete a timer with INT_MAX id if it happens to arrive quickly (a variation of this bug existed before 5b74eed3b301e2227385f3bf26d3bb7c2d822cf8, where the timer would be leaked in this case). So (ab)use cancel field of pthread_t instead.
commit 4486c579cbf0d989080705f515d08cb48636ba88 disabled vdso clock_gettime on arm due to a Linux kernel bug that was not understood at the time, whereby the vdso function silently produced catastrophically wrong results on some systems. since then, the bug was tracked down to the way the arm kernel disabled use of vdso clock_gettime on kernels where the necessary timer was not available or was disabled. it simply patched out the symbols, but it only did this for the legacy time32 functions, and left the time64 function in place but non-operational. kernel commit 4405bdf3c57ec28d606bdf5325f1167505bfdcd4 (first present in 5.8) provided the fix. if this were a bug that impacted all users of the broken kernel versions, we could probably ignore it and assume it had been patched or replaced. however, it's very possible that these kernels appear in the wild in devices running time32 userspace (glibc, musl 1.1.x, or some other environment) where they appear to work fine, but where our new binaries would fail catastrophically if we used the time64 vdso function. since the kernel has not (yet?) given us a way to probe for the working time64 vdso function semantically, we work around the problem by refusing to use the time64 one unless the time32 one is also present. this will revert to not using vdso at all if the time32 one is ever removed, but at least that's safe against wrong results and is just a missed optimization.
the syscall used to probe availability of the clock fails with EINVAL when the requested pid does not exist, but clock_getcpuclockid is specified to use ESRCH for this purpose.
this isolates knowledge of the nonstandard AT_EMPTY_PATH extension to one place and returns __map_file to its prior simplicity.
this function is used to implement some baseline ISO C interfaces, so it cannot call any of the stat functions by their public names. use the namespace-safe __fstatat instead.
riscv32 and future architectures only provide the clock_ functions.
this bug goes back to commit 1cc81f5cb0df2b66a795ff0c26d7bbc4d16e13c6 where zoneinfo file support was first added. in scan_trans, which searches for the appropriate local time/dst rule in effect at a given time, times prior to the second transition time caused the -1 slot of the index to be read to determine the previous rule in effect. this memory was always valid (part of another zoneinfo table in the mapped file) but the byte value read was then used to index another table, possibly going outside the bounds of the mmap. most of the time, the result was limited to misinterpretation of the rule in effect at that time (pre-1900s), but it could produce a crash if adjacent memory was not readable. the root cause of the problem, however, was that the logic for this code path was all wrong. as documented in the comment, times before the first transition should be treated as using the lowest-numbered non-dst rule, or rule 0 if no non-dst rules exist. if the argument is in units of local time, however, the rule prior to the first transition is needed to determine if it falls before or after it, and that's where the -1 index was wrongly used. instead, use the documented logic to find out what rule would be in effect before the first transition, and apply it as the offset if the argument was given in local time. the new code has not been heavily tested, but no longer performs potentially out-of-bounds accesses, and successfully handles the 1883 transition from local mean time to central standard time in the test case the error was reported for.
previously, the contents of the TZ variable were considered a candidate for a file/path name only if they began with a colon or contained a slash before any comma. the latter was very sloppy logic to avoid treating any valid POSIX TZ string as a file name, but it also triggered on values that are not valid POSIX TZ strings, including 3-letter timezone names without any offset. instead, only treat the TZ variable as POSIX form if it begins with a nonzero standard time name followed by +, -, or a digit. also, special case GMT and UTC to always be treated as POSIX form (with implicit zero offset) so that a stray file by the same name cannot break software that depends on setting TZ=GMT or TZ=UTC.
the v1 zoneinfo format with 32-bit time is deprecated. previously, the v2 parsing code was only used if an exact match for '2' was found in the version field of the header. this was already incorrect for v3 files (trivial differences from v2 that arguably didn't merit a new version number anyway) but also failed to be future-proof.
since commit 38143339646a4ccce8afe298c34467767c899f51, the condition sizeof(time_t) > 4 is always true, so there is no functional change being made here. but semantically, the 64-bit tables should always be preferred now, because upstream zic (zoneinfo compiler) has quietly switched to emitting empty 32-bit tables by default, and the resulting backwards-incompatible zoneinfo files will be encountered in the wild.