I noticed that when we build libraries for a different ABI (in CheriBSD) we
were calling ${XCC}/${LD} --version for every directory. It turns out that
this was caused by bsd.compat.mk explicitly setting (X_)COMPILER variables
for that build stage and this stops the _can_export logic from working.
To fix this, we change the check to only set _can_export=no if the variable
is set and it is set to a different value than the cached value.
This noticeably speeds up the tree walk while building compat libraries.
During an upstream amd64 buildworld this also removes 8 --version calls.
Obtained from: CheriBSD
Reviewed By: brooks, emaste
Differential Revision: https://reviews.freebsd.org/D25986
In parallel builds, this should allow sqlite to start building earlier and
increase parallelism when building lib/. Looking at htop output during
buildworld/tinderbox, there are long phases where only one CPU is active
optimizing the massive sqlite3.c file since the build of libsqlite3 is
started quite late.
Reviewed By: emaste
Differential Revision: https://reviews.freebsd.org/D26169
When using relative paths for the linker we have to transform the name
since clang does not like -fuse-ld=ld.lld and instead requires -fuse-ld=lld
(the same also applies for ld.bfd).
-DNO_CLEAN builds have had trouble across the OpenZFS import. It's not
worth the effort to try to address this with any granularity; instead,
just trigger on a .depend file indicating a tree from before the import,
and remove the whole cddl object tree.
Reviewed by: mmacy, kevans
Differential Revision: https://reviews.freebsd.org/D26189
Use unmapped I/O for geli. Unlike most geom providers, geli needs to
manipulate data on every read or write. Previously it would always map bios.
On my 16-core, dual socket server using geli atop md(4) devices, with 512B
sectors, this change increases geli IOPs by about 3x.
Note that geli still can't use unmapped I/O when data integrity verification
is enabled (but it could, with a little more work). And it can't use
unmapped I/O in combination with ZFS, because ZFS uses mapped bios.
Reviewed by: markj, kib, jhb, mjg, mat, bcr (manpages)
MFC after: 1 week
Sponsored by: Axcient
Differential Revision: https://reviews.freebsd.org/D25671
crypto(9) functions can now be used on buffers composed of an array of
vm_page_t structures, such as those stored in an unmapped struct bio. It
requires the running to kernel to support the direct memory map, so not all
architectures can use it.
Reviewed by: markj, kib, jhb, mjg, mat, bcr (manpages)
MFC after: 1 week
Sponsored by: Axcient
Differential Revision: https://reviews.freebsd.org/D25671
The Ampere Altra has physical memory populated sparsely within the
physical address space. Increase the size of the dmap to cover all
physical memory.
Reviewed by: andrew
Approved by: scottl (implicit)
MFC after: 1 week
Sponsored by: Ampere Computing, Inc.
Differential Revision: https://reviews.freebsd.org/D26134
The OsIndications UEFI variable can request the firware to stop at
its UI instead of continuing with boot. Add flags for setting and
clearing this request.
Reviewed by: manu, bcr (manpages)
Approved by: scottl (implicit)
MFC after: 1 week
Sponsored by: Ampere Computing, Inc.
Differential Revision: https://reviews.freebsd.org/D25839
Add a synchronizing instruction to flush and wait until the local
CPU's writes are observable to other CPUs before sending IPIs.
This fixes an issue where recipient CPUs doing a rendezvous could
enter the rendezvous handling code before the initiator's writes
to the smp_rv_* variables were visible. This manifested as a
system hang, where a single CPU's increment of smp_rv_waiters[0]
actually happened "before" the initiator's zeroing of that field,
so all CPUs were stuck with the field appearing to be at
ncpus - 1.
Reviewed by: andrew, markj
Approved by: scottl (implicit)
MFC after: 1 week
Sponsored by: Ampere Computing, Inc.
Differential Revision: https://reviews.freebsd.org/D25798
Please note that neither zstd nor encryption is
supported by the loader at this instant. This
change makes it safe to use those features in
one's root pool, but not in one's root dataset.
Autoscale vm_pageout worker threads from r364129 with CPU count. The
default is arbitrarily chosen to be 16 CPUs per worker thread, but can
be adjusted with the vm.pageout_cpus_per_thread tunable.
There will never be less than 1 thread per populated NUMA domain, and
the previous arbitrary upper limit (at most ncpus/2 threads per NUMA
domain) is preserved.
Care is taken to gracefully handle asymmetric NUMA nodes, such as empty
node systems (e.g., AMD 2990WX) and systems with nodes of varying size
(e.g., some larger >20 core Intel Haswell/Broadwell Xeon).
Reviewed by: kib, markj
Sponsored by: Isilon
Differential Revision: https://reviews.freebsd.org/D26152
performs are protected by an exclusive lock, even for statically linked
programs, it is safe to re-enable libunwind's FrameHeaderCache, which I
temporarily disabled in r364263.
Meanwhile upstream has also used the _LIBUNWIND_USE_FRAME_HEADER_CACHE
for this purpose, so the only thing needed is to add this as a
compile-time command line flag.
While here, reformat the CFLAGS lines a little bit.
MFC after: 6 weeks
X-MFC-With: r364284, r364423
Messing with gnop devices under a zpool fails in this test, causing
the pool to be suspended and eventually the system to deadlock.
Skip the test for now until the issue is resolved.
PR: tests/248910
Discussed with: lwhsu
Sponsored by: iXsystems, Inc.
warnings anymore for compiler-rt's atomic.c. This occurred because the
IS_LOCK_FREE_8 macro was not correctly defined to 0 for mips, and this
caused the compiler to emit a runtime call to __atomic_is_lock_free(),
and that triggers the warning.
MFC after: 2 weeks
X-MFC-With: r364753
I went through the merge and found the rest of the instances where
${MACHINE_ARCH} == "powerpc" was being used to detect 32-bit and adjusted
the rest of the instances to also check for powerpcspe.
mips32* will probably want to do the same.
Sponsored by: Tag1 Consulting, Inc.
The build breaks when something adds -march=<something with BMI> to the
compiler flags, for example CPUTYPE?=native. When the arch supports BMI,
__BMI__ is defined and zstd.c tries to include immintrin.h, which is not
present when building the kernel.
Disable experimental BMI intrinsics in zstd in the OpenZFS kernel module
by explicitly undefining __BMI__ for zstd.c.
A similar fix was needed for the original zstd import, done in r327738.
Reported by: Jakob Alvermark
Discussed with: mmacy
Sponsored by: iXsystems, Inc.
sys/ccompile.h no longer uses #pragma ident, so we no longer need to worry
about unknown pragmas.
I fixed one WARNS issue in r363409 by annotating be_is_auto_snapshot_name's
lbh parameter __unused, then upstreamed the following changes to OpenZFS
that rode in with the merge:
- zfs_path_to_zhandle now takes a const char *path rather than a char *path,
since it won't be mutating the string it receives and I had no reason to
believe it will need to in the future. [OpenZFS PR #10605]
- Annotated some unused parameters on definitions inlined into headers as
such. [OpenZFS PR #10606]
While we do support the "O bit" running a script (usually to start a
dhcpv6 client) we have no options for setups which set the "M bit" for,
e.g., static address assignment as in EC2.
Duplicate most of the "O bit" logic to also start a script for the
"M bit" with the one difference: if the "M bit" is set we will not
start the script for the "O bit" as well (per RFC 4861, Section 4.2).
Reviewed by: hrs, markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D26099
At initialization time, the netmap RX refill function used to
prepare the NIC RX ring with N-1 buffers rather than N (with
N equal to the number of descriptors in the NIC RX ring).
This is not how netmap is supposed to work, as it would keep
kring->nr_hwcur not in sync with the NIC "next index to refill"
(i.e., fl->ifl_pidx). Instead we prepare N buffers, although we
still publish (with isc_rxd_flush()) only the first N-1 buffers,
to avoid the NIC producer pointer to overrun the NIC consumer
pointer (for NICs where this is a real issue, e.g. Intel ones).
MFC after: 2 weeks
For such pages ref_count is effectively a consumer-managed field, but
there is no harm in calling vm_page_wire() on them.
vm_page_unwire_noq() handles them as well. Relax the vm_page_wire()
assertions to permit this case which is triggered by some out-of-tree
code. [1]
Also guard a conditional assertion with INVARIANTS. Otherwise the
conditions are evaluated even though the result is unused. [2]
Reported by: bz, cem [1], kib [2]
Reviewed by: dougm, kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D26173
We need to define the LUA_FLOAT_INT64 macro even if we don't use it (copied
from stand/luaconf.h). While touching luaconf.h.dist also sync it with the
the 5.3.5 release version (matches the one in lib/liblua).
Reviewed By: kevans
Differential Revision: https://reviews.freebsd.org/D25977
The macOS assert.h header does not define static_assert when compiling in
C99 mode. To fix this compile with -std=c11.
Reviewed By: emaste
Differential Revision: https://reviews.freebsd.org/D25928
${TARGET_ARCH} is empty here which results in empy MAKE_PARAMS being
passed to the buildkernel phase. This breaks the build when using the
strict TMPPATH since cc will not be included in $PATH.
Reviewed By: jhb
This should be noticeably faster due to fewer processes being forked and
also handles other flags such as -S or writing to METALOG.
Reviewed By: brooks
Differential Revision: https://reviews.freebsd.org/D26039
This is needed so that setting LD/XLD is not ignored when linking with $CC
instead of directly using $LD. Currently only clang accepts an absolute
path for -fuse-ld= (Clang 12+ will add a new --ld-path flag), so we now
warn when building with GCC and $LD != "ld" since that might result in the
wrong linker being used.
We have been setting XLD=/path/to/cheri/ld.lld in CheriBSD for a long time and
used a similar version of this patch to avoid linking with /usr/bin/ld.
This change is also required when building FreeBSD on an Ubuntu with Clang:
In that case we set XCC=/usr/lib/llvm-10/bin/clang and since
/usr/lib/llvm-10/bin/ does not contain a "ld" binary the build fails with
`clang: error: unable to execute command: Executable "ld" doesn't exist!`
unless we pass -fuse-ld=/usr/lib/llvm-10/bin/ld.lld.
This change passes -fuse-ld instead of copying ${XLD} to WOLRDTMP/bin/ld
since then we would have to ensure that this file does not exist while
building the bootstrap tools. The cross-linker might not be compatible with
the host linker (e.g. when building on macos: host-linker= Mach-O /usr/bin/ld,
cross-linker=LLVM ld.lld).
Reviewed By: brooks, emaste
Differential Revision: https://reviews.freebsd.org/D26055
The most awkward bit in this patch is the bootstrapping of m4:
We can't simply use the host version of m4 since that is not compatible
with the flags passed by lex (at least on macOS, possibly also on Linux).
Therefore we need to bootstrap m4, but lex needs m4 to build and m4 also
depends on lex (which needs m4 to generate any files). To work around this
cyclic dependency we can build a bootstrap version of m4 (with pre-generated
files) then use that to build the real m4.
This patch also changes the xz/unxz/dd tools to always use the host version
since the version in the source tree cannot easily be bootstrapped on macOS
or Linux.
Reviewed By: brooks, imp (earlier version)
Differential Revision: https://reviews.freebsd.org/D25992
In most cases this simply builds the file from lib/libc for missing
functions (e.g. strlcpy on Linux etc.). In cases where this is not possible
I've added an implementation to tools/build/cross-build.
The fgetln.c/fgetwln.c/closefrom.c compatibility code was obtained from
https://gitlab.freedesktop.org/libbsd/libbsd, but I'm not sure it makes
sense to import it into to contrib just for these three bootstrap files.
Reviewed By: brooks
Differential Revision: https://reviews.freebsd.org/D25978
