Association will fail on a secondary open unprotected VAP when the
primary VAP is configured for WPA. Examples of secondary VAPs are,
hotels, universities, and commodity routers' guest networks.
A broadly similar bug was discussed on Red Hat's bugzilla affecting
association to a D-Link DIR-842.
This suggests that as IEs were added to the 802.11 protocol the old code
was increasingly inadaquate to handle the additional IEs, not only a
secondary VAP.
PR: 264238
Reported by: Jaskie <jiangjun12321@gmail.com>
"J.R. Oldroyd" <fbsd@opal.com>
Submitted by: "J.R. Oldroyd" <fbsd@opal.com>
MFC after: 3 days
Merge commit f1b0a4fc540f from llvm git (by Richard Smith):
An expression should only contain an unexpanded parameter pack if it
lexically contains a mention of the pack.
Systematically distinguish between syntactic and semantic references to
packs, especially when propagating dependence from a type into an
expression. We should consult the type-as-written when computing
syntactic dependence and should consult the semantic type when computing
semantic dependence.
Fixes#54402.
MFC after: 3 days
Merge commit 88ce403c6aab from llvm git (by Florian Hahn):
[LV] Add new block to place recurrence splice, if needed.
In some cases, a recurrence splice instructions needs to be inserted
between to regions, for example if the regions get re-arranged during
sinking.
Fixes#56146.
PR: 264979
Reported by: Robert Clausecker <fuz@fuz.su>
MFC after: 3 days
The filter_text function in scripts/functions.sh in version 5.3.3 had
commented out a "rm" command, probably for debugging purposes. This
caused temporary files to persist in /tmp when the bc program had been
built.
This commit fixes the build process with no change of the resulting
artefacts.
(cherry picked from commit 1576f66712)
MFC after: 3 days
In December after a failed MFV due to a now understood issue I had with
git -- git aborts with extremely large MFV -- this patch was removed
during the revert. Restore this patch.
PR: 264238
Fixes: 4b72b91a71
MFC after: 1 week
This update fixes a build issue of release 5.3.2 on the FreeBSD base
system.
Merge commit '3f739b0595b7d6ac4bac9aaa1cae0910f11f92e2'
MFC after: 2 weeks
This version adds support for command line editing and history using
the libedit or readline libraries in addition to the line editing
features available in previous versions.
The version in the base system is configured to use libedit.
This allows to choose between emacs and vi line editing commands and
to use command overrides via a ~/.editrc file.
Merge commit 'bd54318046bfee055b140705a5cfd4148e78da07'
PR: 264010
MFC after: 2 weeks
Merge commit e8305c0b8f49 from llvm git (by Simon Pilgrim)
[X86] combineX86ShuffleChain - don't fold to truncate(concat(V1,V2)) if it was already a PACK op
Fixes#55050
PR: 264394
Reported by: VVD <vvd@unislabs.com>
MFC after: 3 days
Merge commit 18efa420da5f from llvm git (by Brooks Davis)
compiler-rt: Allow build without __c11_atomic_fetch_nand
Don't build atomic fetch nand libcall functions when the required
compiler builtin isn't available. Without this compiler-rt can't be
built with LLVM 13 or earlier.
Not building the libcall functions isn't optimal, but aligns with the
usecase in FreeBSD where compiler-rt from LLVM 14 is built with an LLVM
13 clang and no LLVM 14 clang is built.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D126710
MFC after: 3 days
GNU tools parse macros in the -width argument of lists. mandoc does not,
so it calculates an excessive width. This often squeezes the text into
a very narrow column, especially in nested lists.
Implement the easy workaround suggested in the TODO list. When there is
only one macro, at the beginning of the -width argument, this fixes the
formatting as well as a complete solution.
Reviewed by: bapt
Relnotes: yes
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D35245
Merge commit 45084eab5e63 from llvm git (by Arthur Eubanks):
[clang] Fix some clang->llvm type cache invalidation issues
Take the following as an example
struct z {
z (*p)();
};
z f();
When we attempt to get the LLVM type of f, we recurse into z. z itself
has a function pointer with the same type as f. Given the recursion,
Clang simply treats z::p as a pointer to an empty struct `{}*`. The
LLVM type of f is as expected. So we have two different potential
LLVM types for a given Clang type. If we store one of those into the
cache, when we access the cache with a different context (e.g. we
are/aren't recursing on z) we may get an incorrect result. There is some
attempt to clear the cache in these cases, but it doesn't seem to handle
all cases.
This change makes it so we only use the cache when we are not in any
sort of function context, i.e. `noRecordsBeingLaidOut() &&
FunctionsBeingProcessed.empty()`, which are the cases where we may
decide to choose a different LLVM type for a given Clang type. LLVM
types for builtin types are never recursive so they're always ok.
This allows us to clear the type cache less often (as seen with the
removal of one of the calls to `TypeCache.clear()`). We
still need to clear it when we use a placeholder type then replace it
later with the final type and other dependent types need to be
recalculated.
I've added a check that the cached type matches what we compute. It
triggered in this test case without the fix. It's currently not
check-clang clean so it's not on by default for something like expensive
checks builds.
This change uncovered another issue where the LLVM types for an argument
and its local temporary don't match. For example in type-cache-3, when
expanding z::dc's argument into a temporary alloca, we ConvertType() the
type of z::p which is `void ({}*)*`, which doesn't match the alloca GEP
type of `{}*`.
No noticeable compile time changes:
https://llvm-compile-time-tracker.com/compare.php?from=3918dd6b8acf8c5886b9921138312d1c638b2937&to=50bdec9836ed40e38ece0657f3058e730adffc4c&stat=instructionsFixes#53465.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D118744
PR: 264318
Reported by: mandree
MFC after: 3 days
Merge commit 30baa5d2a450 from llvm git (by Richard Smith):
PR45879: Fix assert when constant evaluating union assignment.
Consider the form of the first operand of a class assignment not the
second operand when implicitly starting the lifetimes of union members.
Also add a missing check that the assignment call actually came from a
syntactic assignment, not from a direct call to `operator=`.
PR: 264280
Reported by: bapt
MFC after: 3 days
This is an initial commit for RDMA FreeBSD driver for Intel(R) Ethernet
Controller E810, called irdma. Supporting both RoCEv2 and iWARP
protocols in per-PF manner, RoCEv2 being the default.
Testing has been done using krping tool, perftest, ucmatose, rping,
ud_pingpong, rc_pingpong and others.
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
Reviewed by: #manpages (pauamma_gundo.com) [documentation]
MFC after: 1 week
Relnotes: yes
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D34690
Merge commit d9d15af7873f from llvm git (Qiu Chaofan):
[PowerPC] Treat llvm.fmuladd intrinsic as using CTR
This fixes bug 55463, similar to D78668. This is a temporary fix since
we will switch to post-isel CTR loop determination in the future.
Reviewed By: dim, shchenz
Differential Revision: https://reviews.llvm.org/D125746
MFC after: 2 weeks
1. Merge LLVM's 315d792130258a9b7250494be8d002ebb427b08f, adding support
for FreeBSD/powerpc64*.
2. Add sanitizer list to lib/libclang_rt/Makefile, taken from the list of
libraries that llvm-devel port builds.
3. powerpc64le supports the same sanitizers that powerpc64, but powerpc64le
also supports xray* sanitizers.
4. lib/libclang_rt/xray/Makefile hardcodes amd64-specific files, so that needs
to be conditionalized.
5. Sanitizers are not enabled for powerpc, because powerpc supports only
builtins and profile.
Reviewed by: dim
Differential Revision: https://reviews.freebsd.org/D35228
Relnotes: yes
MFC after: 3 days
Merge commit 44cdca37c01a from llvm git (by Arthur O'Dwyer):
[libc++] Define `namespace views` in its own detail header.
Discovered in the comments on D118748: we would like this namespace
to exist anytime Ranges exists, regardless of whether concepts syntax
is supported. Also, we'd like to fully granularize the <ranges> header,
which means not putting any loose declarations at the top level.
Differential Revision: https://reviews.llvm.org/D118809
Merge commit 7ab1ab0db401 from llvm git (by Dimitry Andric):
[libc++] Make __dir_stream visibility declaration consistent
The class `__dir_stream` is currently declared in two places: as a
top-level forward declaration in `directory_iterator.h`, and as a friend
declaration in class `directory_entry`, in `directory_entry.h`.
The former has a `_LIBCPP_HIDDEN` attribute, but the latter does not,
causing the Firefox build to complain about the visibility not matching
the previous declaration. This is because Firefox plays games with
pushing and popping visibility.
Work around this by making both `__dir_stream` declarations consistently
use `_LIBCPP_HIDDEN`.
Reviewed By: ldionne, philnik, #libc
Differential Revision: https://reviews.llvm.org/D121639
Merge commit 027c16bef4b7 from llvm git (by Nick Desaulniers):
[X86ISelLowering] permit BlockAddressSDNode "i" constraints for PIC
When building 32b x86 code as PIC, the existing handling of "i"
constraints is conservative since generally we have to go through the
GOT to find references to functions.
But generally, BlockAddresses from C code refer to the Function in the
current TU. Permit BlockAddresses to be used with the "i" constraint
for those cases.
I regressed this in
commit 4edb9983cb8c ("[SelectionDAG] treat X constrained labels as i for asm")
Fixes: https://github.com/llvm/llvm-project/issues/53868
Reviewed By: efriedma, MaskRay
Differential Revision: https://reviews.llvm.org/D119905
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-18294-gdb01b123d012, the last commit before
the upstream release/14.x branch was created.
PR: 261742
MFC after: 2 weeks
In the msg and shm tests, if the child exited before the parent
entered sigsuspend(), the test would hang and time out. This was
also a problem in the sem test, but the misuse of atf_tc_pass()
masked it. Adding a short sleep before the sigsuspend() calls made
the hang 100% reliable. With the same sleep in the new version,
the test passes reliably.
Remove calls to atf_tc_pass(). The call in the sem test broke the test
by exiting prematurely, after only one child out of five had finished.
The other two were harmless but unhelpful.
Reduce a one-second sleep to a more reasonable duration so I can quickly
run many iterations of the test.
Where feasible, assert that wait() returns the child PID. While I'm here,
use the more succinct ATF_REQUIRE* instead of if/atf_tc_fail/else.
Flush stdout before forking to avoid double-flush.
Use errx() when errno is irrelevant.
Don't use ATF_REQUIRE* in children. Apparently, the output doesn't
get saved. The exit status works, so it fails correctly, but silently.
Re-enable the test in CI.
PR: 233649
Reviewed by: markj (previous version)
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D35187
This is a production release that fixes this bc's behavior on ^D to
match GNU bc.
Merge commit 'ed0603704174b01c25b49efc08c82e1532dc5622'
MFC after: 3 days
Padding was added to __cxa_exception in 45ca8b19 and
__cxa_dependent_exception needs the same layout.
Add some static_asserts to detect this in the future.
Merge of libcxxrt commit b00c6c564357
When running binaries compiled with libasan in PIE and with ALSR on,
the previous code always print the WARNING message, the new code only
printed it if the run is made with the right verbosity
Before this change, many unit test will always fail because of the extra
message which is printed
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D35055
MFC after: 2 weeks
o ignore '.POSIX:' if not in first non-comment line
of Makefile as specified by POSIX.
add unit-tests for above.
Merge commit '92bfae0e6bd53a7a0d6fe55e70a916d86cf26e8b'
Fix dialogs building and updating fault with disabled shadow
(conf.shadow=false and implicitly bsddialog --no-shadow).
While here delete WARNS=2: all warnings were fixed in upstream and
imported in 0.2.
Approved by: bapt (mentor)
Differential Revision: https://reviews.freebsd.org/D34958
Insert padding in __cxa_exception struct for compatibility
Similar to https://github.com/llvm/llvm-project/commit/f2a436058fcb, the
addition of __attribute__((__aligned__)) to _Unwind_Exception (in commit
b9616964) causes implicit padding to be inserted before the unwindHeader
field in __cxa_exception.
Applications attempt to get at the earlier fields in __cxa_exception, so
preserve the same negative offsets in __cxa_exception, by moving the
padding to the beginning of the struct.
The assumption here is that if the ABI is not aware of the padding
before unwindHeader and put the referenceCount/primaryException in
there, no padding should exist before unwindHeader.
This should make libreoffice's custom exception handling mechanisms work
correctly, even if it was built against an older cxxabi.h/unwind.h pair.
PR: 263370
MFC after: 3 days
Main change is a callback for checking validity period of certificates.
Merge commit 'f6acb9b9f81c96ae7c9592bee1bb89c4357cc3e5'
Add -DHAVE_BR_X509_TIME_CHECK to libsecureboot/Makefile.inc
This update fixes an issue in input line editing: when going left to
the start of the line, the cursor would jump to the end of the line
instead.
Merge commit 'bc75dcc4ce682562390fa32e7cd63c08160e21b9'
The second argument to pcap_next_ex() is a pointer to a pointer.
Not a pointer. This fixes a wpa_supplicent SIGSEGV.
PR: 263266
Reported by: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl>
Fixes: 6e5d01124f
MFC: immediately
hostapd calls pcap_next(3) to read the next packet off the wlan interface.
pcap_next() returns a pointer to the packet header but does not indicate
success or failure. Unfortunately this results in an infinite loop (100%
CPU) when the wlan device disappears, i.e. when a USB wlan device is
manually removed or a USB error results in the device removal. However
pcap_next_ex(3) does return success or failure. To resolve this we use
pcap_next_ex(), forcing hostapd to exit when the error is encountered.
An error message is printed to syslog or stderr when debugging (-d flag)
is enabled. Unfortunately wpa_printf() only works when debugging is enabled.
PR: 253608
Reported by: Damjan Jovanovic <damjan.jov@gmail.com>,
bz (privately)
MFC after: 3 days
Bugfixes:
IS #1685 and OSS-Fuzz #38764 (security):
(ISO reader) fix possible heap buffer overflow in read_children()
IS #1715 and OSS-Fuzz #46279 (security):
(RARv4 reader) fix heap-use-after-free in run_filters()
MFC after: 3 days
Merge LLVM commit 81f5c6270cdfcdf80e6296df216b696a7a37c8b5.
This fixes runtime of most notably pcre libraries (currently patched in ports),
and probably also other ports since currently __clear_cache() just calls
SIGABRT on powerpc.
MFC after: 3 days
Reviewed by: dim
Differential Revision: https://reviews.freebsd.org/D34736
In contrast to Linux it does not provide entries which can be readlinked
-- these are just regular files, not giving the expected outcome. That's
on top of procfs not being mounted by default to begin with.
Reviewed by: dim
Differential Revision: https://reviews.freebsd.org/D34684
Bugfixes:
IS #1672 and OSS-Fuzz #38766:
(zip reader) fix possible out-of-bounds read in zipx_lzma_alone_init()
PR #1676: (mtree reader) remove the unused variable "detected_bytes"
PR #1674: (doc) fix use of At mdoc(7) macro in cpio.5
MFC after: 3 days
This register set contains the values of the fsbase and gsbase
registers. Note that these registers can already be controlled
individually via ptrace(2) via MD operations, so the main reason for
adding this is to include these register values in core dumps. In
particular, this will enable looking up the value of TLS variables
from core dumps in gdb.
The value of NT_X86_SEGBASES was chosen to match the value of
NT_386_TLS on Linux. The notes serve similar purposes, but FreeBSD
will never dump a note equivalent to NT_386_TLS (which dumps a single
segment descriptor rather than a pair of addresses) and picking a
currently-unused value in the NT_X86_* range could result in a future
conflict.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D34650
Summary:
Without it building rust fails with:
ld: error: CallSiteSplitting.cpp:(function llvm::SmallVectorImpl<std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<std::__1::pair<llvm::ICmpInst*, unsigned int>, 2u> > >::operator=(llvm::SmallVectorImpl<std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<std::__1::pair<llvm::ICmpInst*, unsigned int>, 2u> > >&&): .text._ZN4llvm15SmallVectorImplINSt3__14pairIPNS_10BasicBlockENS_11SmallVectorINS2_IPNS_8ICmpInstEjEELj2EEEEEEaSEOSB_+0xB0): relocation R_PPC_PLTREL24 out of range: -33582208 is not in [-33554432, 33554431]
This will need to be merged to releng/13.1.
Reviewed by: dim
Differential Revision: https://reviews.freebsd.org/D34652
MFC after: 3 days
This register set exposes the per-thread TLS register. It matches the
layout used by Linux on arm64. Linux does not implement this note for
32-bit arm.
Reviewed by: andrew, markj
Sponsored by: University of Cambridge, Google, Inc.
Differential Revision: https://reviews.freebsd.org/D34595
Fix unlock in two-word version and add missing comment.
Fixes#15Fixes#16
This should fix the hangs in __cxa_guard_acquire() reported on i386 (and
possibly other 32-bit platforms).
Obtained from: https://github.com/libcxxrt/libcxxrt/commit/f2e5509
Fixes: 56aaed388b
MFC after: 2 weeks
This reapplies upstream commit fd484be, as there is a follow-up fix for
the possible hangs in __cxa_guard_acquire() on i386:
Atomics cleanup (#11)
We need to test exception specifiers but they're gone in C++17 so
compile the tests with an older version of the standard.
Rewrite the guard logic to be more idiomatic C++ and more
comprehensible and make sure that atomics are used where necessary.
Obtained from: https://github.com/libcxxrt/libcxxrt/commit/fd484be
Fixes: 56aaed388b
MFC after: 2 weeks
After merging llvm commit b9ca73e1a8fd for PR 262608, it would fail to
compile with:
/usr/src/contrib/llvm-project/llvm/lib/IR/Operator.cpp:197:22: error: no member named 'isZero' in 'llvm::APInt'
if (!IndexedSize.isZero()) {
~~~~~~~~~~~ ^
Upstream refactored their APInt class, and isZero() was one of the newer
methods which did not yet exist in llvm 13.0.0. Fix this by using the
older but equivalent isNullValue() method instead.
Fixes: 1b3bef43e3
MFC after: 3 days
Merge commit b9ca73e1a8fd from llvm git (by Stephen Tozer):
[DebugInfo] Correctly handle arrays with 0-width elements in GEP salvaging
Fixes an issue where GEP salvaging did not properly account for GEP
instructions which stepped over array elements of width 0 (effectively a
no-op). This unnecessarily produced long expressions by appending
`... + (x * 0)` and potentially extended the number of SSA values used
in the dbg.value. This also erroneously triggered an assert in the
salvage function that the element width would be strictly positive.
These issues are resolved by simply ignoring these useless operands.
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D111809
PR: 262608
Reported by: Damjan Jovanovic <damjan.jov@gmail.com>
MFC after: 3 days
This reverts upstream commit fd484be:
Atomics cleanup (#11)
We need to test exception specifiers but they're gone in C++17 so
compile the tests with an older version of the standard.
Rewrite the guard logic to be more idiomatic C++ and more
comprehensible and make sure that atomics are used where necessary.
It looks like there are some corner cases in the i386 and/or 32-bit
atomics handling, which can make __cxa_guard_acquire() hang in certain
situations.
Reported by: antoine
Obtained from: https://github.com/libcxxrt/libcxxrt/commit/fd484be
Fixes: 56aaed388b
MFC after: 2 weeks
This reverts 9097e3cbca, which was in itself a revert of upstream
libcxxrt commits 88bdf6b290da ("Specify double-word alignment for ARM
unwind") and b96169641f79 ("Updated Itanium unwind"), and a
reapplication of our commit 3c4fd2463b ("libcxxrt: add padding in
__cxa_allocate_* to fix alignment").
The editors/libreoffice port will be patched to be able to cope with the
standards-compliant alignment of _Unwind_Exception and consequently,
that of __cxa_exception. The layouts and sizes of these structures
should then be completely the same for libcxxrt, libunwind and
libc++abi.
PR: 262008
Reviewed by: emaste, jhb, theraven
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D34488
This version fixes a parse error when passing a file to bc using -f
if that file has a multiline comment or string in it.
Merge commit '3673adf1ee311d6f83176d3e43cf0efb314764e4'
MFC after: 3 days
Merge commit f457863ae345 from llvm git (by Fangrui Song):
[ELF] Support REL-format R_AARCH64_NONE relocation
-fprofile-use=/-fprofile-sample-use= compiles may produce REL-format
.rel.llvm.call-graph-profile even if the prevailing format is RELA on AArch64.
Add R_AARCH64_NONE to getImplicitAddend to fix this linker error:
```
ld.lld: error: internal linker error: cannot read addend for relocation R_AARCH64_NONE
PLEASE submit a bug report to https://crbug.com and run tools/clang/scripts/process_crashreports.py (only works inside Google) which will upload a report and include the crash backtrace.
```
Merge commit 53fc5d9b9a01 from llvm git (by Fangrui Song):
[ELF] Support R_PPC_NONE/R_PPC64_NONE in getImplicitAddend
Similar to f457863ae345d2635026501f5383e0e625869639
Merge commit 767e64fc11d7 from llvm git (by Fangrui Song):
[ELF] Support some absolute/PC-relative relocation types for REL format
ctfconvert seems to use REL-format `.rel.SUNW_dof` for 32-bit architectures.
```
Binary file usr/ports/lang/perl5.32/work/perl-5.32.1/dtrace_mini.o matches
[alfredo.junior@dell-a ~/tmp/llvm-bug]$ readelf -r dtrace_mini.o
Relocation section (.rel.SUNW_dof):
r_offset r_info r_type st_value st_name
00000184 0000281a R_PPC_REL32 00000000 $dtrace1772974259.Perl_dtrace_probe_load
```
Support R_PPC_REL32 to fix `ld.lld: error: drti.c:(.SUNW_dof+0x4E4): internal linker error: cannot read addend for relocation R_PPC_REL32`.
While here, add some common relocation types for AArch64, PPC, and PPC64.
We perform minimum tests.
Reviewed By: adalava, arichardson
Differential Revision: https://reviews.llvm.org/D120535
Requested by: alfredo
MFC after: 3 days
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
Update unbound manpages by copying the current unbound manpages in
contrib/doc/*.in to their respective manpages,
PR: 262013
Reported by: Michael Osipov <michael.osipov@siemens.com>
Fixes: numerous previous updates
MFC after: 3 days
NetBSD has an ATF test for newfs_msdos. Connect it to the build.
Adapt it for FreeBSD. This would have caught the bug fixed by my
previous commit.
Reviewed by: delphij, emaste
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D34116
Libarchive 3.6.0
New features:
PR #1614: tar: new option "--no-read-sparse"
PR #1503: RAR reader: filter support
PR #1585: RAR5 reader: self-extracting archive support
New features (not used in FreeBSD base):
PR #1567: tar: threads support for zstd (#1567)
PR #1518: ZIP reader: zstd decompression support
Security Fixes:
PR #1491, #1492, #1493, CVE-2021-36976:
fix invalid memory access and out of bounds read in RAR5 reader
PR #1566, #1618, CVE-2021-31566:
extended fix for following symlinks when processing the fixup list
Other notable bugfixes and improvements:
PR #1620: tar: respect "--ignore-zeros" in c, r and u modes
PR #1625: reduced size of application binaries
MFC after: 2 weeks
Relnotes: yes
* unit-tests/Makefile: disable opt-debug-x-trace on Linux if there
is any chance we have dash as .SHELL
* meta.c: use a variable to hold command line to be filtered
to avoid any side effects from content of command line.
Merge commit '535c59a6a9214436f5d6643775d29808e4b3408d'
Libarchive 3.6.0
New features:
PR #1614: tar: new option "--no-read-sparse"
PR #1503: RAR reader: filter support
PR #1585: RAR5 reader: self-extracting archive support
New features (not used in FreeBSD base):
PR #1567: tar: threads support for zstd (#1567)
PR #1518: ZIP reader: zstd decompression support
Security Fixes:
PR #1491, #1492, #1493, CVE-2021-36976:
fix invalid memory access and out of bounds read in RAR5 reader
PR #1566, #1618, CVE-2021-31566:
extended fix for following symlinks when processing the fixup list
Other notable bugfixes and improvements:
PR #1620: tar: respect "--ignore-zeros" in c, r and u modes
PR #1625: reduced size of application binaries
Obtained from: libarchive
Libarchive commit: 9147def1da7ad1bdd47b3559eb1bfeeb0e0f374b
Libarchive tag: v3.6.0
It fails during GitHub cross-build actions from Ubuntu 20.04.
sjg investigated and found it is a dash bug; a more extensive change
to handle this case will come in the next bmake update.
Reviewed by: sjg
Differential Revision: https://reviews.freebsd.org/D34219
Merge commit 28fb22c90fe7 from llvm git (by Dimitry Andric):
[TSan] Handle FreeBSD specific indirection of libpthread functions
Similar to 60cc1d3218fc for NetBSD, add aliases and interceptors for the
following pthread related functions:
- pthread_cond_init(3)
- pthread_cond_destroy(3)
- pthread_cond_signal(3)
- pthread_cond_broadcast(3)
- pthread_cond_wait(3)
- pthread_mutex_init(3)
- pthread_mutex_destroy(3)
- pthread_mutex_lock(3)
- pthread_mutex_trylock(3)
- pthread_mutex_unlock(3)
- pthread_rwlock_init(3)
- pthread_rwlock_destroy(3)
- pthread_rwlock_rdlock(3)
- pthread_rwlock_tryrdlock(3)
- pthread_rwlock_wrlock(3)
- pthread_rwlock_trywrlock(3)
- pthread_rwlock_unlock(3)
- pthread_once(3)
- pthread_sigmask(3)
In FreeBSD's libc, a number of internal aliases of the pthread functions
are invoked, typically with an additional prefixed underscore, e.g.
_pthread_cond_init() and so on.
ThreadSanitizer needs to intercept these aliases too, otherwise some
false positive reports about data races might be produced.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D119034
MFC after: 3 days
getline() returns -1 on erorr or EOF, so use that condition instead of
feof() and check that there was no error after the loop exits.
Reviewed by: bapt, kevans (both earlier)
MFC after: 3 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34159
This release assigns a default value to the internal program name
variable in case the program is invoked with argv[0] == NULL.
There was no security issue: the prevuous program version would have
been immediately terminated due to a NULL dereference.
Some sanitizers (at least msan) currently require ASLR to be disabled.
When we detect that ASLR is enabled, re-exec with it disabled rather
than exiting with an error. See LLVM GitHub issue 53256 for more
detail: https://github.com/llvm/llvm-project/issues/53256
No objection: dim
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33934
Based on getMainExecutable() in llvm/lib/Support/Unix/Path.inc.
This will need a little more work for an upstream change as it must
support older FreeBSD releases that lack elf_aux_info() / AT_EXEC_PATH.
No objection: dim
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33934
