summaryrefslogtreecommitdiff
path: root/src/time
AgeCommit message (Collapse)AuthorLines
2022-09-19fix thread leak on timer_create(SIGEV_THREAD) failureAlexey Izbyshev-1/+5
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.
2022-09-19re-enable vdso clock_gettime on arm (32-bit) with workaroundRich Felker-0/+3
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.
2022-08-01fix ESRCH error handling for clock_getcpuclockidEugene Yudin-0/+1
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.
2022-05-04use __fstat instead of __fstatat with AT_EMPTY_PATH in __map_fileRich Felker-2/+1
this isolates knowledge of the nonstandard AT_EMPTY_PATH extension to one place and returns __map_file to its prior simplicity.
2022-05-01drop direct use of stat syscalls in internal __map_fileRich Felker-3/+3
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.
2022-05-01only fallback to gettimeofday/settimeofday syscalls if they existStefan O'Rear-0/+4
riscv32 and future architectures only provide the clock_ functions.
2022-02-09fix out-of-bound read processing time zone data with distant-past datesRich Felker-14/+12
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.
2021-06-23fix TZ parsing logic for identifying POSIX-form stringsRich Felker-1/+13
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.
2020-11-22parse v3 or future-unknown zoneinfo file versions as v2+Rich Felker-1/+1
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.
2020-11-22explicitly prefer 64-bit/v2 zoneinfo tablesRich Felker-1/+1
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.
2020-11-11lift child restrictions after multi-threaded forkRich Felker-0/+2
as the outcome of Austin Group tracker issue #62, future editions of POSIX have dropped the requirement that fork be AS-safe. this allows but does not require implementations to synchronize fork with internal locks and give forked children of multithreaded parents a partly or fully unrestricted execution environment where they can continue to use the standard library (per POSIX, they can only portably use AS-safe functions). up until recently, taking this allowance did not seem desirable. however, commit 8ed2bd8bfcb4ea6448afb55a941f4b5b2b0398c0 exposed the extent to which applications and libraries are depending on the ability to use malloc and other non-AS-safe interfaces in MT-forked children, by converting latent very-low-probability catastrophic state corruption into predictable deadlock. dealing with the fallout has been a huge burden for users/distros. while it looks like most of the non-portable usage in applications could be fixed given sufficient effort, at least some of it seems to occur in language runtimes which are exposing the ability to run unrestricted code in the child as part of the contract with the programmer. any attempt at fixing such contracts is not just a technical problem but a social one, and is probably not tractable. this patch extends the fork function to take locks for all libc singletons in the parent, and release or reset those locks in the child, so that when the underlying fork operation takes place, the state protected by these locks is consistent and ready for the child to use. locking is skipped in the case where the parent is single-threaded so as not to interfere with legacy AS-safety property of fork in single-threaded programs. lock order is mostly arbitrary, but the malloc locks (including bump allocator in case it's used) must be taken after the locks on any subsystems that might use malloc, and non-AS-safe locks cannot be taken while the thread list lock is held, imposing a requirement that it be taken last.
2020-11-11convert malloc use under libc-internal locks to use internal allocatorRich Felker-0/+5
this change lifts undocumented restrictions on calls by replacement mallocs to libc functions that might take these locks, and sets the stage for lifting restrictions on the child execution environment after multithreaded fork. care is taken to #define macros to replace all four functions (malloc, calloc, realloc, free) even if not all of them will be used, using an undefined symbol name for the ones intended not to be used so that any inadvertent future use will be caught at compile time rather than directed to the wrong implementation.
2020-10-28add support for SIGEV_THREAD_ID timersJames Y Knight-2/+6
This is like SIGEV_SIGNAL, but targeted to a particular thread's tid, rather than the process.
2020-10-14drop use of pthread_once in timer_createRich Felker-10/+7
this makes the code slightly smaller and eliminates timer_create from relevance to possible future changes to multithreaded fork. the barrier of a_store isn't technically needed here, but a_store is used anyway for internal consistency of the memory model.
2020-10-14remove unused SIGTIMER handler in timer_createRich Felker-6/+1
this was leftover from when the actual SIGEV_THREAD timer logic was in the signal handler. commit 5b74eed3b301e2227385f3bf26d3bb7c2d822cf8 replaced that with use of sigwaitinfo, with the actual signal left blocked, so the no-op signal handler was no longer serving any purpose. the signal disposition reset to SIG_DFL is still needed, however, in case we inherited SIG_IGN from a foreign-libc process.
2020-03-21fix parsing offsets after long timezone namesSamuel Holland-5/+5
TZ containg a timezone name with >TZNAME_MAX characters currently breaks musl's timezone parsing. getname() stops after TZNAME_MAX characters. getoff() will consume no characters (because the next character is not a digit) and incorrectly return 0. Then, because there are remaining alphabetic characters, __daylight == 1, and dst_off == -3600. getname() must consume the entire timezone name, even if it will not fit in d/__tzname, so when it returns, s points to the offset digits.
2020-03-21avoid out-of-bounds read for invalid quoted timezoneSamuel Holland-2/+2
Parsing the timezone name must stop when reaching the null terminator. In that case, there is no '>' to skip.
2020-02-12fix remaining direct use of stat syscalls outside fstatat.cRich Felker-1/+2
because struct stat is no longer assumed to correspond to the structure used by the stat-family syscalls, it's not valid to make any of these syscalls directly using a buffer of type struct stat. commit 9493892021eac4edf1776d945bcdd3f7a96f6978 moved all logic around this change for stat-family functions into fstatat.c, making the others wrappers for it. but a few other direct uses of the syscall were overlooked. the ones in tmpnam/tempnam are harmless since the syscalls are just used to test for file existence. however, the uses in fchmodat and __map_file depend on getting accurate file properties, and these functions may actually have been broken one or more mips variants due to removal of conversion hacks from syscall_arch.h. as a low-risk fix, simply use struct kstat in place of struct stat in the affected places.
2019-09-25fix data race in timer_create with SIGEV_THREAD notificationRich Felker-2/+2
in the timer thread start function, self->timer_id was accessed without synchronization; the timer thread could fail to see the store from the calling thread, resulting in timer_delete failing to delete the correct kernel-level timer. this fix is based on a patch by changdiankang, but with the load moved to after receiving the timer_delete signal rather than just after the start barrier, so as not to retain the possibility of data race with timer_delete.
2019-08-07in clock_getres, check for null pointer before storing resultRich Felker-1/+1
POSIX allows a null pointer, in which case the function only checks the validity of the clock id argument.
2019-08-07remove spurious null check in clock_settimeRich Felker-1/+1
at the point of this check, the pointer has already been dereferenced. clock_settime is not defined for null pointer arguments.
2019-08-05fix regression in clock_gettime on 32-bit archs without vdsoRich Felker-0/+1
commit 72f50245d018af0c31b38dec83c557a4e5dd1ea8 broke this by creating a code path where r is uninitialized.
2019-08-02clock_gettime: add support for 32-bit vdso with 64-bit time_tRich Felker-0/+32
this fixes a major upcoming performance regression introduced by commit 72f50245d018af0c31b38dec83c557a4e5dd1ea8, whereby 32-bit archs would lose vdso clock_gettime after switching to 64-bit time_t, unless the kernel supports time64 and provides a time64 version of the vdso function. this would incur not just one but two syscalls: first, the failed time64 syscall, then the fallback time32 one. overflow of the 32-bit result is detected and triggers a revert to syscalls. normally, on a system that's not Y2038-ready, this would still overflow, but if the process has been migrated to a time64-capable kernel or if the kernel has been hot-patched to add time64 syscalls, it may conceivably work.
2019-08-02clock_gettime: add time64 syscall support, decouple 32-bit time_tRich Felker-0/+19
the time64 syscall has to be used if time_t is 64-bit, since there's no way of knowing before making a syscall whether the result will fit in 32 bits, and the 32-bit syscalls do not report overflow as an error. on 64-bit archs, there is no change to the code after preprocessing. on current 32-bit archs, the result is now read from the kernel through long[2] array, then copied into the timespec, to remove the assumption that time_t is the same as long. vdso clock_gettime is still used in place of a syscall if available. 32-bit archs with 64-bit time_t must use the time64 version of the vdso function; if it's not available, performance will significantly suffer. support for both vdso functions could be added, but would break the ability to move a long-lived process from a pre-time64 kernel to one that can outlast Y2038 with checkpoint/resume, at least without added hacks to identify that the 32-bit function is no longer usable and stop using it (e.g. by seeing negative tv_sec). this possibility may be explored in future work on the function.
2019-07-29clock_getres: don't assume time_t is 32-bit on 32-bit archsRich Felker-0/+14
the time64 syscall for this is not necessary or useful, since clock resolution is generally better than 68-year granularity. if there's a 32-bit syscall, use it and expand the result into timespec; otherwise there is only one syscall and it does the right thing to store to timespec directly. on 64-bit archs, there is no change to the code after preprocessing.
2019-07-29timer_gettime: add time64 syscall support, decouple 32-bit time_tRich Felker-0/+16
the time64 syscall has to be used if time_t is 64-bit, since there's no way of knowing before making a syscall whether the result will fit in 32 bits, and the 32-bit syscalls do not report overflow as an error. on 64-bit archs, there is no change to the code after preprocessing. on current 32-bit archs, the result is now read from the kernel through long[4] array, then copied into the timespec, to remove the assumption that time_t is the same as long.
2019-07-29clock_settime: add time64 syscall support, decouple 32-bit time_tRich Felker-0/+17
time64 syscall is used only if it's the only one defined for the arch, or if the requested time does not fit in 32 bits. on current 32-bit archs where time_t is a 32-bit type, this makes it statically unreachable. if the time64 syscall is needed because the requested time does not fit in 32 bits, we define this as an error ENOTSUP, for "The implementation does not support the requested feature or value". on 64-bit archs, there is no change to the code after preprocessing. on current 32-bit archs, the time is moved through an intermediate copy to remove the assumption that time_t is a 32-bit type.
2019-07-29timer_settime: add support for time64 syscall, decouple 32-bit time_tRich Felker-0/+25
time64 syscall is used only if it's the only one defined for the arch, if either component of the itimerspec does not fit in 32 bits, or if time_t is 64-bit and the caller requested the old value, in which case there's a possibility that the old value might not fit in 32 bits. on current 32-bit archs where time_t is a 32-bit type, this makes it statically unreachable. on 64-bit archs, there is no change to the code after preprocessing. on current 32-bit archs, the time is moved through an intermediate copy to remove the assumption that time_t is a 32-bit type.
2019-07-28clock_nanosleep: add time64 syscall support, decouple 32-bit time_tRich Felker-0/+25
time64 syscall is used only if it's the only one defined for the arch, or if the requested time does not fit in 32 bits. on current 32-bit archs where time_t is a 32-bit type, this makes it statically unreachable. on 64-bit archs, there is no change to the code after preprocessing. on current 32-bit archs, the time is moved through an intermediate copy to remove the assumption that time_t is a 32-bit type.
2019-07-27refactor thrd_sleep and nanosleep in terms of clock_nanosleepRich Felker-4/+8
for namespace-safety with thrd_sleep, this requires an alias, which is also added. this eliminates all but one direct call point for nanosleep syscalls, and arranges that 64-bit time_t conversion logic will only need to exist in one file rather than three. as a bonus, clock_nanosleep with CLOCK_REALTIME and empty flags is now implemented as SYS_nanosleep, thereby working on older kernels that may lack POSIX clocks functionality.
2019-02-15always block signals for starting new threads, refactor start argsRich Felker-1/+0
whether signals need to be blocked at thread start, and whether unblocking is necessary in the entry point function, has historically depended on intricacies of the cancellation design and on whether there are scheduling operations to perform on the new thread before its successful creation can be committed. future changes to track an AS-safe list of live threads will require signals to be blocked whenever changes are made to the list, so ... prior to commits b8742f32602add243ee2ce74d804015463726899 and 40bae2d32fd6f3ffea437fa745ad38a1fe77b27e, a signal mask for the entry function to restore was part of the pthread structure. it was removed to trim down the size of the structure, which both saved a small amount of stack space and improved code generation on archs where small immediate displacements are less costly than arbitrary ones, by limiting the range of offsets between the base of the thread structure, its members, and the thread pointer. these commits moved the saved mask to a special structure used only when special scheduling was needed, in which case the pthread_create caller and new thread had to synchronize with each other and could use this memory to pass a mask. this commit partially reverts the above two commits, but instead of putting the mask back in the pthread structure, it moves all "start argument" members out of the pthread structure, trimming it down further, and puts them in a separate structure passed on the new thread's stack. the code path for explicit scheduling of the new thread is also changed to synchronize with the calling thread in such a way to avoid spurious futex wakes.
2019-02-15for SIGEV_THREAD timer threads, replace signal handler with sigwaitinfoRich Felker-21/+16
this eliminates some ugly hacks that were repurposing the start function and start argument fields in the pthread structure for timer use, and the need to longjmp out of a signal handler.
2019-01-21fix call to __pthread_tsd_run_dtors with too many argumentsRich Felker-1/+1
commit a6054e3c94aa0491d7366e4b05ae0d73f661bfe2 removed the argument, making it a constraint violation to pass one. caught by cparser/firm; other compilers seem to ignore it.
2018-10-22don't omit setting errno in internal __map_file functionRich Felker-2/+2
a caller needs the reason for open (or fstat, albeit unlikely) failure if it's going to make decisions about continuing a path search or similar.
2018-09-15always reset DST rules during tzsetBenjamin Peterson-1/+2
do_tzset() did't always reset the DST transition rules r0 and r1. That means the rules from older TZ settings could leak into newer ones.
2018-09-12split internal lock API out of libc.h, creating lock.hRich Felker-0/+1
this further reduces the number of source files which need to include libc.h and thereby be potentially exposed to libc global state and internals. this will also facilitate further improvements like adding an inline fast-path, if we want to do so later.
2018-09-12reduce spurious inclusion of libc.hRich Felker-8/+1
libc.h was intended to be a header for access to global libc state and related interfaces, but ended up included all over the place because it was the way to get the weak_alias macro. most of the inclusions removed here are places where weak_alias was needed. a few were recently introduced for hidden. some go all the way back to when libc.h defined CANCELPT_BEGIN and _END, and all (wrongly implemented) cancellation points had to include it. remaining spurious users are mostly callers of the LOCK/UNLOCK macros and files that use the LFS64 macro to define the awful *64 aliases. in a few places, new inclusion of libc.h is added because several internal headers no longer implicitly include libc.h. declarations for __lockfile and __unlockfile are moved from libc.h to stdio_impl.h so that the latter does not need libc.h. putting them in libc.h made no sense at all, since the macros in stdio_impl.h are needed to use them correctly anyway.
2018-09-12move declaration and apply hidden visibility to __utc stringRich Felker-4/+1
2018-09-12remove or make static various unused __-prefixed symbolsRich Felker-1/+1
2018-09-12apply hidden visibility to internal time[zone] implementation functionsRich Felker-8/+8
2018-09-12overhaul internally-public declarations using wrapper headersRich Felker-23/+1
commits leading up to this one have moved the vast majority of libc-internal interface declarations to appropriate internal headers, allowing them to be type-checked and setting the stage to limit their visibility. the ones that have not yet been moved are mostly namespace-protected aliases for standard/public interfaces, which exist to facilitate implementing plain C functions in terms of POSIX functionality, or C or POSIX functionality in terms of extensions that are not standardized. some don't quite fit this description, but are "internally public" interfacs between subsystems of libc. rather than create a number of newly-named headers to declare these functions, and having to add explicit include directives for them to every source file where they're needed, I have introduced a method of wrapping the corresponding public headers. parallel to the public headers in $(srcdir)/include, we now have wrappers in $(srcdir)/src/include that come earlier in the include path order. they include the public header they're wrapping, then add declarations for namespace-protected versions of the same interfaces and any "internally public" interfaces for the subsystem they correspond to. along these lines, the wrapper for features.h is now responsible for the definition of the hidden, weak, and weak_alias macros. this means source files will no longer need to include any special headers to access these features. over time, it is my expectation that the scope of what is "internally public" will expand, reducing the number of source files which need to include *_impl.h and related headers down to those which are actually implementing the corresponding subsystems, not just using them.
2018-09-12move declarations of tls setup/access functions to pthread_impl.hRich Felker-2/+0
it's already included in all places where these are needed, and aside from __tls_get_addr, they're all implementation internals.
2018-09-12move __strftime_fmt_1 declaration to time_impl.hRich Felker-2/+2
this is a helper function from strftime that's also used by wcsftime.
2018-09-12move __tm_to_tzname declaration to time_impl.h with related functionsRich Felker-1/+1
this function was added later for strftime use and the existence of time_impl.h as the appropriate place for it seems to have been overlooked.
2018-09-12fix type-mismatched declarations of __nl_langinfo_l in source filesRich Felker-2/+2
obviously the type "should be" const, but it inherited non-const from the standard nl_langinfo_l.
2018-09-12use idiomatic weak alias approach for defining asctime_rRich Felker-33/+28
get rid of a gratuitous translation unit and call frame between asctime_r and the actual implementation of the function. this is the way gmtime_r and localtime_r are already done.
2018-09-12move and deduplicate declarations of __vdsosym to make it checkableRich Felker-2/+0
2018-08-27time: fix incorrect DST offset when using POSIX timezones without DSTA. Wilcox-1/+1
This manifests itself in mktime if tm_isdst = 1 and the current TZ= is a POSIX timezone specification. mktime would see that tm_isdst was set to 0 by __secs_to_zone, and subtract 'oppoff' (dst_off) - gmtoff from the resultant time. This meant that mktime returned a time that was exactly double the GMT offset of the desired timezone when tm_isdst was = 1.
2018-08-07fix sign of strftime %z output with offsets <1 hour west of UTCRich Felker-3/+2
the sign character produced came from the sign of tm_gmtoff/3600 as an integer division, which is zero for negative offsets smaller in magnitude than 3600. instead of printing the hours and minutes as separate fields, print them as a single value of the form hours*100+minutes, which naturally has the correct sign.
2018-06-26strftime: fix underlying format string in %z formatDaniel Sabogal-1/+1
the expression (tm->__tm_gmtoff)/3600 has type long. use %+.2ld instead.