Whilst /bin/echo on macOS and Linux implement -n, as do the builtin
echos in bash and zsh, the builtin echo in dash does not, causing the
first line of the output to be -n foo rather than just foo, and there to
be an extra newline in the output and thus blank line, both of which
result in "Symbol ... is not present in *.kld" warnings appearing in the
build output (once for -n foo and once for the empty string for each
module where EXPORT_SYMS is a list of symbols).
MFC after: 1 week
Use autonegotiated link speed value while updating link status
to iflib.
This patch is part of change made in NetBSD kernel
by Masanobu Saitoh, NetBSD maintainer.
Differential Revision: https://reviews.freebsd.org/D19176
Approved by: erj
Explicitly add pfsync as a know upper layer protocol so we don't
automatically discard pfsync packets (carried over IPv6).
net.inet6.ip6.fw.deny_unknown_exthdrs defaults to 1, so even if
net.inet.ip.fw.default_to_accept is set to 1 we'd discard pfsync (over
IPv6).
Reviewed by: ae
Differential Revision: https://reviews.freebsd.org/D40973
The right unwinding stop indicator should be CFI-undefined PC.
https://dwarfstd.org/doc/Dwarf3.pdf - page 118:
If a Return Address register is defined in the virtual unwind table,
and its rule is undefined (for example, by DW_CFA_undefined), then
there is no return address and no call address, and the virtual
unwind of stack activations is complete.
The hack localizing _start1 symbol removed.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D40624
Normally, modern unwinders uses Dwarf information to unwind stack,
however in case when the code is not annotated by Dwarf instructions,
unwinders fallbacks to a frame-pointer based algorithm.
That is allows libunwind to unwind stack from global constructors and
destructors. Also it makes gdb happy as it printed nonexistent frame
before.
Reviewed by: kib, imp
Differential Revision: https://reviews.freebsd.org/D40948
Add a stop indicator to rtld_start to satisfy unwinders:
The right unwinding stop indicator should be CFI-undefined PC.
https://dwarfstd.org/doc/Dwarf3.pdf - page 118:
If a Return Address register is defined in the virtual unwind table,
and its rule is undefined (for example, by DW_CFA_undefined), then
there is no return address and no call address, and the virtual
unwind of stack activations is complete.
That is allows gdb and libunwind successfully stop when unwinding stack
from global constructors and destructors.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D40949
Initial stack pointer is preserved in calle-saved %esi,
use it bellow to pass initial stack pointer to _rtld().
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D40950
This matches the beadm behavior; generally, we need to keep promoting
until the BE is no longer a clone from a snapshot. This fixes scenarios
where the dataset associated with a BE's origin is itself a clone,
activating the BE previously would promote it to a clone of the origin's
origin.
We could keep using be_get_dataset_props here, except for two
annoyances:
1.) I couldn't find a clean way to just clear an nvlist rather than
having to re-alloc it, and I didn't want to just remove the one prop
we're inspecting out of it.
2.) That's a lot of overhead when all we want to do is fetch the origin
anyways.
Note that this is not a complete fix, but it does fix the majority of
cases; deep BE subordinates are still notably broken, pending a patch
from Christian.
Reported by: R. Christian McDonald <rcm@rcm.sh>
Reviewed by: rew
Differential Revision: https://reviews.freebsd.org/D40903
The default per-queue packet rate of 8000 will cause packet loss when
forwarding at 2.5G with a single stream, as is common when using e.g.
iperf3 to test a platform.
Bump this to 20000 (the "low latency" value in the Linux driver) which
avoids packet loss for this type of test.
Future work will use adaptive interrupt rate in a similar fashion
to the ixgbe driver.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Reviewed by: erj, kp
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D40904
These are useful for testing new additions to the script. Whilst here,
harden the script a little and improve error messages.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D31007
We run depend-cleanup.sh twice during the build. The second time is the
normal run, where we run it under WMAKEENV and thus have CROSSENV's
MACHINE(_ARCH)=${TARGET(_ARCH)} in the environment. However, the first
time is for bootstrap-tools, where it's run under BMAKEENV and we don't
have any assignments to MACHINE(_ARCH) in the environment, meaning the
script sees them as unset. In practice this doesn't matter since the
only use doesn't apply to bootstrap-tools, but it could be a future
issue. Thus, explicitly export them for depend-cleanup.sh and have the
script verify they're set.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D40968
It contains arbitrary garbage, which is not cleared by vfs_bio_clrbuf()
which only zeroes invalid portions of the pages.
Reported by: Maxim Suhanov <dfirblog@gmail.com>
Discussed with: so
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Now that depend-cleanup.sh handles 32-bit dependencies a bit better, get
rid of the stale ffs.S ones, otherwise an incremental build on amd64
will fail with:
cc: error: no such file or directory: '/usr/src/lib/libc/i386/string/ffs.S'
Fixes: ee8b0c436d
For example with the recent removal of ffs.S for 32-bit arm and i386,
the egrep in clean_dep() did not find any files to remove, even if you
added a "clean_dep lib/libc ffs S" line. This is because it will never
find the ffs.S filename in the 64-bit .depend files for libc.
Split the searching and removing of 32-bit dependencies and objects into
a separate part to cope with this. This can be used similarly later on,
for other bitnesses.
MFC after: 3 days
* Wait for gnop devices to disappear after "gnop destroy".
Apparently that process is asynchronous now, or maybe it's just slower
than it used to be. Also, after removing a gnop wait for its pool to
be degraded. That isn't instant.
* The zfsd tests no longer require camcontrol.
This was a harmless oversight from
11ed0a95bf
* Fix the zfsd_degrade_001_pos test for recent zfs versions.
ZFS now rate limits checksum errors to about 20 per second. But
zfsd's threshold for degrading a disk is 50 per minute. So we must
alternately corrupt and scrub the pool to ensure that checksum errors
are generated in multiple 1-second windows, so that zfsd will see
enough of them.
* Fix the zfsd_fault_001_pos test in VMs
And, for that matter, when using NVME or SATA disks. As originally
written, the test used the da driver to inject errors. Rewrite it to
use gnop vdevs. gnop can also inject errors. It works on top of any
disk device, and it's also faster than using da.
MFC after: 2 weeks
Sponsored by: Axcient
Differential Revision: https://reviews.freebsd.org/D39437
At some point the names of these devd events changed. Probably it
happened when importing OpenZFS. Before that, FreeBSD's sysevent_alloc
method didn't create a "class" nvpair in the event, which led to
log_sysevent using the event's ev_subclass field as its type.
MFC after: 2 weeks
Sponsored by: Axcient
Differential Revision: https://reviews.freebsd.org/D39437
This just stages the kernel and builds a stripped-down rootfs for use
with the Firecracker VMM. At some point in the future the release
engineering team might start publishing these, but initially it's
just here to simplify FreeBSD/Firecracker development and testing.
Note that the rootfs generated:
* Uses an IP address of 10.0.0.2 with a gateway of 10.0.0.1,
* Has sshd enabled,
* Has user "freebsd" with password "freebsd" and a root password
of "root", and
* Is 1 GB in size (but has growfs enabled).
All of those are subject to change without notice; anyone intending to
use FreeBSD/Firecracker in anything remotely resembling a production
environment should talk to cperciva first.
Reviewed by: gjb
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D40956
Only i386 still uses a 32-bit time_t. I knew this, and I still failed
to compile-test on i386. My bad.
Reported by: cy
Fixes: c210cac00f ("dhclient: fix time parsing for leases...")
Sponsored by: Dell EMC Isilon
It points to non-existent documentation. The wiki page still contains a
useful overview, so keep this link.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
This utility has existed for a long time and should not be advertised as
"currently under development".
While here, fix the one other warning from igor about using a newline
for a new sentence.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Convert lease parsing to timegm to calculate timestamp. For reference, when
writing the lease, we use gmtime to convert the timestamp to struct tm.
Reviewed By: markj, vangyzen
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D40760
Previously, even if the FIONBIO or FIOASYNC ioctl failed, the file's
f_flags variable would still be changed. Now, kern_fcntl will restore
the original flags if the ioctl fails.
PR: 265736
Reported by: Yuval Pavel Zholkover <paulzhol@gmail.com>
MFC after: 2 weeks
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D40955
These are present (and empty) on a system installed post-GCC removal.
Reviewed by: imp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D40878
Two cases in the insert routine are written differently, when
they're really doing the same thing. Writing that case only once
saves 208 bytes in the compiled vm_radix_insert code and reduces
instructions executed by about 2%.
Reviewed by: alc
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D40807
The examples I wrote previously do not work. We parse the flags using
explicit names, not the shortened flag suffix. Fix the list of major
flags, and add a compact list of minor flags. Fix the examples, and
tweak some wording for clarity.
Reviewed by: jkoshy, emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Fixes: 5fc97cc325 ("hwpmc(4): document debugging options")
Differential Revision: https://reviews.freebsd.org/D40913
These are no longer referenced, with the one user of each now using the
double-underscore version with "32" as an argument instead.
Reviewed by: kib, brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40935
This will allow the latter to be removed, reducing the boilerplate
needed for a new libcompat.
Reviewed by: kib, brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40934
This will allow the latter to be removed, reducing the boilerplate
needed for a new libcompat.
Reviewed by: kib, brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40933
See commit 8fad2cda93 ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.
Reviewed by: emaste, brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40932
In the process, delete a COMPAT_SOFTFP remnant that was missed in
previous sweeps.
See commit 8fad2cda93 ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.
Reviewed by: emaste, brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40931
The use isn't any more generic, just the variable itself, which will
allow COMPAT_32BIT to be removed. The fact we even have to check
COMPAT_LIBCOMPAT here in order to pass the right flags to CPP points at
our libcompat infrastructure not suitably modifying the CPP variable
(which we barely use for world; this and bsd.symver.mk are the two
uses, and the latter could benefit from the right flags too), but this
change doesn't attempt to fix that.
See commit 8fad2cda93 ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.
Reviewed by: emaste, imp, brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40930
See commit 8fad2cda93 ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.
Reviewed by: brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40929
See commit 8fad2cda93 ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.
Reviewed by: imp, brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40927
See commit 8fad2cda93 ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.
Reviewed by: emaste, imp, brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40926
We still have a tiny amount of libcompat-specific code in rtld_paths.h,
but it's been deduplicated as much as possible, and in future we may
wish to just push these variables down to the few consumers of them and
make them use the double-underscore variants with a libcompat argument
rather than give them names here.
See commit 8fad2cda93 ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.
Reviewed by: kib, brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40925
See commit 8fad2cda93 ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.
Reviewed by: emaste, brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40924
See commit 8fad2cda93 ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.
Reviewed by: brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40923
Currently the only way to detect for a libcompat build is to consult
whether COMPAT_32BIT is defined (or equivalent, for downstreams with
other libcompats or past releases with libsoft as COMPAT_SOFTFP). There
are two issues with this:
1. COMPAT_32BIT is a new naming scheme that doesn't match the libcompat
name, which is unnecessary deviation.
2. When multiple libcompats exist, everywhere that needs to detect a
libcompat must check each variable in turn, despite the fact that it
normally just wants to know if this is a libcompat build and perhaps
what ${LIBCOMPAT} and/or ${libcompat} are for it.
As a result, far too many places in the tree need to know about the set
of possible libcompats.
Instead, introduce two new CPP and sub-make variables, COMPAT_LIBCOMPAT
and COMPAT_libcompat, which give the values for ${LIBCOMPAT} and
${libcompat} respectively, so that uses can be made parameterised. For
when code really does need to know the specific libcompat, Makefiles can
perform a string comparison, but the C preprocessor cannot, so introduce
an additional CPP-only COMPAT_LIB${LIBCOMPAT} which is intended to
replace the inconsistently-named COMPAT_32BIT (which will be removed in
future). Uses of this new variable should still be kept to a minimum,
however, given the code duplication needed for new libcompats.
Reviewed by: emaste, brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40922
Currently none of the words in these require quoting, but a future
commit will add words that do, thus we should make sure to quote each
word so the shell doesn't mangle them before calling the sub-make.
(Note that :@var@expr@ is the bmake syntax for map, replacing each word
with expr's evaluation, with var containing the input word)
Reviewed by: emaste, brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40921
Having the symbols exported by libc differ between i386 and amd64 lib32
is questionable. Since these files build just fine today, stop guarding
them with !defined(COMPAT_32BIT). Whether or not they work at run time
is a different matter, but an i386 jail would be similarly affected if
not, so that's not a problem with lib32.
Reviewed by: kib, jhb, imp
Differential Revision: https://reviews.freebsd.org/D40937