-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
These headers are required in order to build the bootstrap tools on macOS
and Linux. A follow-up commit will add implementations of functions that
don't exist on those operating systems to -legacy when bootstrapping.
Reviewed By: brooks
Differential Revision: https://reviews.freebsd.org/D14316
of acked bytes as described in Section 2.2 of that document.
This patch ensures that this limit is not also applied in congestion
avoidance. Applying this limit also in congestion avoidance can result in
using less bandwidth than allowed.
Reported by: l.tian.email@gmail.com
Reviewed by: rrs, rscheff
MFC after: 3 days
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D26120
There have been several mentions on our mailing lists about missing
atomic functions in our system libraries (e.g. __atomic_load_8 and
friends), and recently I saw __bswapdi2 and __bswapsi2 mentioned too.
To address this, add implementations for the functions from compiler-rt
to the system compiler support libraries, e.g. libcompiler_rt.a and and
libgcc_s.so.
This also needs a small fixup in compiler-rt's atomic.c, to ensure that
32-bit mips can build correctly.
Bump __FreeBSD_version to make it easier for port maintainers to detect
when these functions were added.
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D26159
The primary benefit is maintaining a completely shared
code base with the community allowing FreeBSD to receive
new features sooner and with less effort.
I would advise against doing 'zpool upgrade'
or creating indispensable pools using new
features until this change has had a month+
to soak.
Work on merging FreeBSD support in to what was
at the time "ZFS on Linux" began in August 2018.
I first publicly proposed transitioning FreeBSD
to (new) OpenZFS on December 18th, 2018. FreeBSD
support in OpenZFS was finally completed in December
2019. A CFT for downstreaming OpenZFS support in
to FreeBSD was first issued on July 8th. All issues
that were reported have been addressed or, for
a couple of less critical matters there are
pull requests in progress with OpenZFS. iXsystems
has tested and dogfooded extensively internally.
The TrueNAS 12 release is based on OpenZFS with
some additional features that have not yet made
it upstream.
Improvements include:
project quotas, encrypted datasets,
allocation classes, vectorized raidz,
vectorized checksums, various command line
improvements, zstd compression.
Thanks to those who have helped along the way:
Ryan Moeller, Allan Jude, Zack Welch, and many
others.
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D25872
r358097 introduced a problem for i386, where kernel builds will intermittently
get hung, typically with many processes sleeping on "btalloc".
I know nothing about VM, but received assistance from rlibby@ and markj@.
rlibby@ stated the following:
It looks like the problem is that
for systems that do not have UMA_MD_SMALL_ALLOC, we do
uma_zone_set_allocf(vmem_bt_zone, vmem_bt_alloc);
but we haven't set an appropriate free function. This is probably why
UMA_ZONE_NOFREE was originally there. When NOFREE was removed, it was
appropriate for systems with uma_small_alloc.
So by default we get page_free as our free function. That calls
kmem_free, which calls vmem_free ... but we do our allocs with
vmem_xalloc. I'm not positive, but I think the problem is that in
effect we vmem_xalloc -> vmem_free, not vmem_xfree.
Three possible fixes:
1: The one you tested, but this is not best for systems with
uma_small_alloc.
2: Pass UMA_ZONE_NOFREE conditional on UMA_MD_SMALL_ALLOC.
3: Actually provide an appropriate vmem_bt_free function.
I think we should just do option 2 with a comment, it's simple and it's
what we used to do. I'm not sure how much benefit we would see from
option 3, but it's more work.
This patch implements #2. I haven't done a comment, since I don't know
what the problem is.
markj@ noted the following:
I think the suggested patch is ok, but not for the reason stated.
On platforms without a direct map the problem is:
to allocate btags we need a slab,
and to allocate a slab we need to map a page, and to map a page we need
to allocate btags.
We handle this recursion using a custom slab allocator which specifies
M_USE_RESERVE, allowing it to dip into a reserve of free btags.
Because the returned slab can be used to keep the reserve populated,
this ensures that there are always enough free btags available to
handle the recursion.
UMA_ZONE_NOFREE ensures that we never reclaim free slabs from the zone.
However, when it was removed, an apparent bug in UMA was exposed:
keg_drain() ignores the reservation set by uma_zone_reserve()
in vmem_startup().
So under memory pressure we reclaim the free btags that are needed to
break the recursion.
That's why adding _NOFREE back fixes the problem: it disables the
reclamation.
We could perhaps fix it more cleverly, by modifying keg_drain() to always
leave uk_reserve slabs available.
markj@'s initial patch failed testing, so committing this patch was agreed
upon as the interim solution.
Either rlibby@ or markj@ might choose to add a comment to it.
PR: 248008
Reviewed by: rlibby, markj
Update the deprecation message in the drm2 (aka legacy drm) drivers to point
towards the graphics/drm-kmod ports for all architectures, not just amd64.
drm-kmod has support for more architectures these days, and the
graphics/drm-legacy-kmod port is being deprecated.
Approved by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D26174
