src/lib/libc, branch release/13.1.0

time(3): Refine history in the manual page

2022-04-22T14:36:36Z

The time() system call first appeared in Version 1 AT&T UNIX. Through the Version 3 AT&T UNIX, it returned 60 Hz ticks since an epoch that changed occasionally, because it was a 32-bit value that overflowed in a little over 2 years. In Version 4 AT&T UNIX the granularity of the return value was reduced to whole seconds, delaying the aforementioned overflow until 2038. Version 7 AT&T UNIX introduced the ftime() system call, which returned time at a millisecond level, though retained the gtime() system call (exposed as time() in userland). time() could have been implemented as a wrapper around ftime(), but that wasn't done. 4.1cBSD implemented a higher-precision time function gettimeofday() to replace ftime() and reimplemented time() in terms of that. Since FreeBSD 9 the implementation of time() uses clock_gettime(CLOCK_SECOND) instead of gettimeofday() for performance reasons. With most valuable input from Warner (imp@). Reviewed by: 0mp, jilles, imp Approved by: re (gjb) Differential Revision: https://reviews.freebsd.org/D34751 (cherry picked from commit 3e0f3678eca7c3f296b9f702992737356f1792da)

Mostly revert a5970a529c2d95271: Make files opened with O_PATH to not block non-forced unmount

2022-04-19T21:03:16Z

Approved by: re (gjb) (cherry picked from commit bf13db086b84c29ce901145f2800c561dcbf4d1e) (cherry picked from commit 6daddc54debbf590cae17bead4864c7f640c07d0)

libc: Restore fp state upon flush error in fputc

2022-03-31T15:56:37Z

This is akin to commit bafaa70b6f9098d83d074968c8e6747ecec1e118. Approved by: re (gjb) Reported by: Guy Yur Fixes: 86a16ada1ea6 Sponsored by: The FreeBSD Foundation (cherry picked from commit 6e13794fbe6e82c21365d0fd66769bf8b19c0197) (cherry picked from commit 7be0c792c46c5a1faf46b611058953aa85b192d6)

amd64: bring back asm bcmp, shared with memcmp

2022-03-29T12:40:32Z

Turns out clang converts "memcmp(foo, bar, len) == 0" and similar to bcmp calls. Reviewed by: emaste (previous version), jhb (previous version) Differential Revision: https://reviews.freebsd.org/D34673 Approved by: re (gjb) (cherry picked from commit fbc002cb72d2d9bb435cce99630d5d7da9f59390) (cherry picked from commit c5890784f6d315c501586b39cf8c0c80b609be5b)

libc __sfvwrite(): roll back FILE buffer pointer on fflush error

2022-03-14T15:47:24Z

__sfvwrite() advances the pointer before calling fflush. If fflush() fails, it is not enough to roll back inside it, because we cannot know how much was advanced by the caller. Reported by: Peter Approved by: re (gjb) Reviewed by: markj Sponsored by: The FreeBSD Foundation Fixes: 86a16ada1ea608408cec370171d9f59353e97c77 (cherry picked from commit bafaa70b6f9098d83d074968c8e6747ecec1e118) (cherry picked from commit 647f02d68a60b66d063a15feed3c817966114d52)

powerpc: enable initial-exec TLS

2022-03-08T00:28:33Z

Summary: Use initial-exec, like other architectures. While here, switch MACHINE_ARCH in lib/libc/Makefile to LIBC_ARCH and consistently use powerpc. Subscribers: imp, #contributor_reviews_base Differential Revision: https://reviews.freebsd.org/D34315 Reviewed by: luporl MFC after: 2 weeks (cherry picked from commit 884ba43116d4456d5900d3c8824153c604f132b8)

fd: add close_range(..., CLOSE_RANGE_CLOEXEC)

2022-03-07T12:15:47Z

For compatibility with Linux. MFC after: 3 days Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D34424 (cherry picked from commit f3f3e3c44d3b1776653bbf19eab17ce006a815d8)

libc: return partial sysctl() result if buffer is too small

2022-03-04T19:54:00Z

Testing of a new feature revealed that calling sysctl() to retrieve the value of the user.localbase variable passing too low a buffer size could leave the result buffer unchanged. The behavior in the normal case of a sufficiently large buffer was correct. All known callers pass a sufficiently large buffer and have thus not been affected by this issue. If a non-default value had been assigned to this variable, the result was as documented, too. Fix the function to fill the buffer with a partial result, if the passed in buffer size is too low to hold the full result. (cherry picked from commit e11ad014d1468729ecf758ab3709618a78feae1b) libc: add helper furnction to set sysctl() user.* variables Testing had revealed that trying to retrieve the user.localbase variable into to small a buffer would return the correct error code, but would not fill the available buffer space with a partial result. A partial result is of no use, but this is still a violation of the documented behavior, which has been fixed in the previous commit to this function. I just checked the code for "user.cs_path" and found that it had the same issue. Instead of fixing the logic for each user.* sysctl string variable individually, this commit adds a helper function set_user_str() that implements the semantics specified in the sysctl() man page. It is currently only used for "user.cs_path" and "user.localbase", but it will offer a significant simplification when further such variables will be added (as I intend to do). (cherry picked from commit 9535d9f104d82487abfc3a64de18f9d010bba6d2) sysctlbyname(): restore access to user variables The optimization of sysctlbyname() in commit d05b53e0baee7 had the side-effect of not going through the fix-up for the user.* variables in the previously called sysctl() function. This lead to 0 or an empty strings being returned by sysctlbyname() for all user.* variables. An alternate implementation would store the user variables in the kernel during system start-up. That would allow to remove the fix-up code in the C library that is currently required to provide the actual values. This update restores the previous code path for the user.* variables and keeps the performance optimization intact for all other variables. (cherry picked from commit af7d105379a649b7af4bffd15fbeab692bb52b69)

fread.c: fix undefined behavior

2022-03-04T19:47:23Z

A case of undefined behavior in __fread() has been detected by UBSAN and reported by Mark Millard: /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero offset to null pointer SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior in /usr/main-src/lib/libc/stdio/fread.c:133:10 While being benign (the NULL pointer is later passed to memcpy() with a length argument of 0), this issue causes in the order of 600 Kyua test cases to fail on systems running a world built with WITH_UBSAN and WITH_ASAN. The undefined behavior can be prevented by skipping operations that have no effect for r == 0. Mark Millard has suggested to only skip this code segment if fp->_p == NULL, but I have verified that for the case of r == 0 no further argument checking is performed on the addresses passed to memcpy() and thus no bugs are hidden from the sanitizers due to the simpler condition chosen. (cherry picked from commit 10af8e45a89818754b80315539e167ae49599f17)

qsort.c: prevent undefined behavior

2022-03-04T19:47:02Z

Mark Milliard has detected a case of undefined behavior with the LLVM UBSAN. The mandoc program called qsort with a==NULL and n==0, which is allowed by the POSIX standard. The qsort() in FreeBSD did not attempt to perform any accesses using the passed pointer for n==0, but it did add an offset to the pointer value, which is undefined behavior in case of a NULL pointer. This operation has no adverse effects on any achitecture supported by FreeBSD, but could be caught in more strict environments. After some discussion in the freebsd-current mail list, it was concluded that the case of a==NULL and n!=0 should still be caught by UBSAN (or cause a program abort due to an illegal access) in order to not hide errors in programs incorrectly invoking qsort(). Only the the case of a==NULL and n==0 should be fixed to not perform the undefined operation on a NULL pointer. This commit makes qsort() exit before reaching the point of potentially undefined behvior for the case n==0, but does not test the value of a, since the result will not depend on whether this pointer is NULL or an actual pointer to an array if n==0. The issue found by Mark Milliard in the whatis command has been reported to the upstream (OpenBSD) and has already been patched there. (cherry picked from commit d106f982a54cd299671ccad58bc456138a22ae7b)