[OpenMP] Fix child processes to use affinity_none (#91391)
When a child process is forked with OpenMP already initialized, the
child process resets its affinity mask and sets proc-bind-var to false
so that the entire original affinity mask is used. This patch corrects
an issue with the affinity initialization code setting affinity to
compact instead of none for this special case of forked children.
The test trying to catch this only testing explicit setting of
KMP_AFFINITY=none. Add test run for no KMP_AFFINITY setting.
Fixes: #91098
This should fix OpenMP processes sometimes getting stuck on a single CPU
core.
PR: 278845
Reported by: Cassidy B. Larson <cbl@cbl.us>
MFC after: 3 days
(cherry picked from commit 22b3e7898e)
[OpenMP] Fix re-locking hang found in issue 86684 (#88539)
This was initially reported here (including stacktraces):
https://stackoverflow.com/questions/78183545/does-compiling-imagick-with-openmp-enabled-in-freebsd-13-2-cause-sched-yield
If `__kmp_register_library_startup()` detects that another instance of
the library is present, `__kmp_is_address_mapped()` is eventually
called. which uses `kmpc_alloc()` to allocate memory. This function
calls `__kmp_entry_thread()` to access the thread-local memory pool,
which is a bad idea during initialization. This macro internally calls
`__kmp_get_global_thread_id_reg()` which sets the bootstrap lock at the
beginning (before calling `__kmp_register_library_startup()`).
The fix is to use `KMP_INTERNAL_MALLOC()`/`KMP_INTERNAL_FREE()` instead
of `kmpc_malloc()`/`kmpc_free()`. `KMP_INTERNAL_MALLOC` and
`KMP_INTERNAL_FREE` do not use any bootstrap locks. They just translate
to `malloc()`/`free()` and are meant to be used during library
initialization before other library-specific allocators have been
initialized.
Fixes: #86684
This should fix OpenMP processes sometimes getting locked with 100% CPU
usage, endlessly calling sched_yield(2).
PR: 278845
Reported by: Cassidy B. Larson <cbl@cbl.us>
MFC after: 3 days
(cherry picked from commit da15ed2e98)
RFC8881 specifies that, when a Link operation occurs on an
NFSv4, that file delegations issued to other clients must
be recalled. Discovered during a recent discussion on nfsv4@ietf.org.
Although I have not observed a problem caused by not doing
the required delegation recall, it is definitely required
by the RFC, so this patch makes the server do the recall.
Tested during a recent NFSv4 IETF Bakeathon event.
(cherry picked from commit 3f65000b6b)
This is a total hack/bare minimum which follows inet4.
Otherwise 2 threads removing the same address can easily crash.
Reviewed by: kp
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D39317
(cherry picked from commit f5a365e51f)
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1159
(cherry picked from commit 65767e6126)
if_bridge: Minor style fixes
And more comments on the #ifdef INET blocks to improve readability.
While here, revert the order of two prototypes to produce minimal diff
compared to stable branches.
(cherry picked from commit 73585176ff)
(cherry picked from commit d45f1f5193)
The if_bridge contains several instances of:
if (AF_INET code ...
#ifdef INET6
AF_INET6 code ...
#endif
) {
...
Clean this up by adding a couple of macros at the top of the file that
are conditionally defined based on whether INET and/or INET6 are enabled,
which makes the code more readable and easier to maintain.
No functional change intended.
Reviewed by: zlei, markj
MFC after: 1 week
Pull Request: https://github.com/freebsd/freebsd-src/pull/1191
(cherry picked from commit ef84dd8f49)
(cherry picked from commit 2f95e4a01e)
If 'td_lend_user_pri' has the expected value, there is no need to check
the fields that sched_lend_user_prio() modifies, they either are already
good or soon will be ('td->td_lend_user_pri' has just been changed by
a concurrent update).
Reviewed by: kib
Approved by: emaste (mentor)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44050
(cherry picked from commit aeff15b392)
Approved by: emaste (mentor)
There is no need to have it for the priority check (that the thread
doesn't have a higher priority than the mutex's ceiling), and there's
also no need to take it if the thread doesn't have privileges to set its
priority to the mutex's ceiling.
While here, turn 'su' into a 'bool' and compute the internal priority
corresponding to the mutex's ceiling once and for all, putting it in new
'new_pri'.
Reviewed by: kib
Approved by: emaste (mentor)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44045
(cherry picked from commit 39e4665c96)
Approved by: emaste (mentor)
Doing this instead of using the current (user) priority, which includes
current lendings, prevents gratuitous failures for threads involved in
multiple locking groups, where each group is defined as the threads that
can lock a particular PP or PI mutex. No deadlock can occur in this
case. Indeed, if a thread holds such a lock A giving it a higher
priority than the ceiling of some other lock B that is PP, and B is
acquired by another thread, effectively the latter may not be able to
run but this situation can only last until the first thread releases A,
which it will do eventually.
Reviewed by: kib
Approved by: emaste (mentor)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44044
(cherry picked from commit 9ac3ac9ece)
Approved by: emaste (mentor)
'uq_inherited_pri' contains the current priority inherited from Priority
Protection mutexes. If -1 is passed through 'm_ceilings[1]', meaning
that there are no such mutexes held anymore, this must be reflected into
it by setting it to PRI_MAX, regardless of whether the thread has
privilege to set realtime priorities (PRI_MAX is also obviously not
a realtime priority level). By contrast, it shall not be updated and
the computed 'new_inherited_pri' shall stay unused if the thread doesn't
have the ability to set a realtime priority, possibly keeping an older
such priority acquired previously.
Reviewed by: kib
Approved by: emaste (mentor)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D43984
(cherry picked from commit 1df8700aa6)
Approved by: emaste (mentor)
This caused adduser to produce an invalid `pw(8)` command line. Due to
bugs in `pw(8)`, the command line was silently accepted and led to the
user being created, but locked out and with no home directory.
Also fix the default value for the “Another user?” prompt.
Fixes: 170d088290
MFC after: 3 days
Reviewed by: karels, allanjude
Differential Revision: https://reviews.freebsd.org/D45098
(cherry picked from commit 46c4e86ebf)
Rename `M_PRINT` and `M_UPDATE` to `M_SHOW` and `M_MODIFY` to match the
names of the commands they represent. No functional change intended.
MFC after: 3 days
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D45096
(cherry picked from commit a9ea647c29)
pw: Don't silently ignore unparsed command line arguments.
MFC after: 3 days
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D45097
(cherry picked from commit c86119328e)
pw: Test home directory ownership and mode.
MFC after: 3 days
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D45099
(cherry picked from commit e12b7446bd)
Fix the following problem:
1. A nonexistent user, someuser, is added to somegroup in /etc/group.
2. someuser is then created with membership in somegroup.
The entry for somegroup in /etc/group will then contain
somegroup:*:12345:someuser,someuser
With this fix, the entry will be
somegroup:*:12345:someuser
PR: 238995
Reviewed by: bapt, jrm
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41076
(cherry picked from commit 17839f45d8)
The WITH_LLVM_TARGET_ENABLE_SPARC option was removed a long time ago,
but some ifdefs were still laying around, so clean them up.
PR: 276104
MFC after: 3 days
(cherry picked from commit 6f44401900)
Update version numbers, config headers, etc. Git tricked me into losing
these before pushing.
PR: 276104
Fixes: d67fc74b9249
MFC after: 3 days
(cherry picked from commit 894cb08f0d)
As kib@ noted:
> Obviously gettimeofday(2) is not going to be removed
> even in the far future.
Reported by: kib
Fixes: 4395d3ced5 Document that gettimeofday() is obsolescent
MFC after: 3 days
(cherry picked from commit 6662c2312e)
#2147 archive_string: clean up strncat_from_utf8_to_utf8 (36047967a)
#2153 archive_match: check archive_read_support_format_raw()
return value (0ce1b4c38)
#2154 archive_match: turn counter into flag (287e05d53)
#2155 lha: Do not allow negative file sizes (93b11caed)
#2156 tests: setenv LANG to en_US.UTF-8 in bsdunzip test_I.c (83e8b0ea8)
(cherry picked from commit c0b58e65de)
Libarchive 3.7.3
New features:
#1941 uudecode filter: support file name and file mode in raw mode
#1943 7-zip reader: translate Windows permissions into UNIX
permissions
#1962 zstd filter now supports the "long" write option
#2012 add trailing letter b to bsdtar(1) substitute pattern
#2031 PCRE2 support
#2054 add support for long options "--group" and "--owner" to tar(1)
Security fixes:
#2101 Fix possible vulnerability in tar error reporting introduced
in f27c173
Important bugfixes:
#1974 ISO9660: preserve the natural order of links
#2105 rar5: fix infinite loop if during rar5 decompression the last
block produced no data
#2027 xz filter: fix incorrect eof at the end of an lzip member
#2043 zip: fix end-of-data marker processing when decompressing zip
archives
(cherry picked from commit b9128a37fa)
Unzip from FreeBSD has been ported to libarchive.
Change usr.bin/unzip to use bsdunzip from libarchive.
Differential Revision: https://reviews.freebsd.org/D41239
PR: 272845 (exp-run)
(cherry picked from commit b5a3a89c50)
Libarchive 3.7.0
Important changes (relevant to FreeBSD):
#1814 Do not account for NULL terminator when comparing with "TRAILER!!!"
#1818 Add ability to produce multi-frame zstd archives
#1840 year 2038 fix for pax archives on platforms with 64-bit time_t
#1860 Make single bit bitfields unsigned to avoid clang 16 warning
#1869 Fix FreeBSD builds with WARNS=6
#1873 bsdunzip ported to libarchive from FreeBSD
#1894 read support for zstd compression in 7zip archives
#1918 ARM64 filter support in 7zip archives
(cherry picked from commit e64fe029e9)
This is a minimal workaround; a proper fix will come via a future update
from upstream.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit e23d45187b)
OPENSSL_API_COMPAT can be used to specify the OpenSSL API version in
use for the purpose of hiding deprecated interfaces and enabling
the appropriate deprecation notices.
This change is a NFC while we're still using OpenSSL 1.1.1 but will
avoid deprecation warnings upon the switch to OpenSSL 3.0.
A future update should migrate to use the OpenSSL 3.0 APIs.
PR: 271615
Reviewed by: emaste
Event: Kitchener-Waterloo Hackathon 202305
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 5a7500dab9)
macOS, like Linux, does not include an outer const qualifier for its
fts_open callback arguments, so -Wincompatible-function-pointer-types
also picks this up and breaks the build now Clang 16 makes it an error
by default. Extend the existing Linux support to fix this.
MFC after: 1 week
(cherry picked from commit 75464941dc)
macOS, like Linux, does not include an outer const qualifier for its
fts_open callback arguments, so -Wincompatible-function-pointer-types
also picks this up and breaks the build now Clang 16 makes it an error
by default. Extend the existing Linux support to fix this.
MFC after: 1 week
(cherry picked from commit d8c84215d7)
macOS, like Linux, does not include an outer const qualifier for its
fts_open callback arguments, so -Wincompatible-function-pointer-types
also picks this up and breaks the build now Clang 16 makes it an error
by default. Extend the existing Linux support to fix this.
MFC after: 1 week
(cherry picked from commit ce312ef72d)
The glibc fts_open() callback type does not have the second const
qualifier and it appears that Clang 16 errors by default for mismatched
function pointer types. Add an ifdef to handle this case.
Reviewed By: imp, emaste
Differential Revision: https://reviews.freebsd.org/D43000
(cherry picked from commit 60e845ceef)
It appears that Clang 16 errors by default for the mismatched function
pointer types that are triggered by the fts callback (since glibc has a
callback type without the second const qualifier).
Fortunately, there is already code to handle glibc inside mandoc, we
just have to edit the checked-in config.h.
Reviewed By: imp, emaste
Differential Revision: https://reviews.freebsd.org/D42999
(cherry picked from commit 0156465c6d)
