pf_route() sends traffic to a specified next hop over a specific
interface. The next hop is obtained in pf_map_addr() but the interface
is obtained directly via r->rpool.cur->kif` outside of the lock held in
pf_map_addr() in multiple places around pf. The chosen interface is not
stored in source node.
Move the interface selection into pf_map_addr(), have the function
return it together with the chosen IP address and ensure its stored
in struct pf_ksrc_node, store it in the source node and use the stored
value when needed.
Sponsored by: InnoGames GmbH
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D41570
The mount subcommand currently produces output such as:
# bectl mount <bootenv>
Successfully mounted <bootenv> at <mountpoint>
This commit changes it to only print the mountpoint:
# bectl mount <bootenv>
<mountpoint>
This makes it easier to script the mount subcommand. If an error occurs
while mounting, an error message is printed to stderr and bectl will
exit with a non-zero value.
PR: 273180
Reviewed by: kevans, asomers
Differential Revision: https://reviews.freebsd.org/D41562
We currently pass MACHINE and MACHINE_ARCH as TARGET and TARGET_ARCH
respectively for universe-toolchain, but on non-FreeBSD these may not
have values that we understand (e.g. on Linux it will be x86_64 rather
than amd64) for TARGET/TARGET_ARCH (note that we do support them for
MACHINE/MACHINE_ARCH). Since the choice is a bit arbitrary and merely
determines what LLVM's default triple will be, use amd64 on non-FreeBSD
as a known-good default.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D41545
The top-level Makefile passes -m to its sub-makes in order to ensure
they use the in-tree mk files in share/mk, but the top-level make itself
has to rely on whatever environment the bmake used has. For FreeBSD, we
configure the system bmake with .../share/mk:/usr/share/mk, which means
it will pick up src's share/mk whenever run from within the src tree,
but currently for non-FreeBSD we configure our bootstrap bmake only with
bmake's own mk files. This is mostly compatible, with two exceptions:
1. "targets" runs at the top level, but needs TARGET_MACHINE_LIST and
the corresponding MACHINE_ARCH_LIST_${target}, otherwise it will just
print an empty list.
2. "universe" and "universe-toolchain", when run at the top level (i.e.
not via the various wrappers around universe like tinderbox), end up
failing in universe-toolchain itself with:
bmake[1]: "/path/to/freebsd/share/mk/src.sys.obj.mk" line 112: Cannot use MAKEOBJDIR=
Unset MAKEOBJDIR to get default: MAKEOBJDIR='${.CURDIR:S,^${SRCTOP},${OBJTOP},}'
By including .../share/mk in the default sys path like FreeBSD's system
bmake we ensure that we get the in-tree mk files for the top-level make,
not just sub-makes, and avoid such issues.
Note that we cannot (yet) stop using the installed mk files, since the
MAKEOBJDIRPREFIX check in Makefile runs in the object directory and uses
env -i, thereby losing the MAKESYSPATH exported by src.sys.env.mk. Other
such issues may also exist, though are likely rare if so.
Reviewed by: sjg
Differential Revision: https://reviews.freebsd.org/D41544
We currently assume that any existing bootstrapped bmake binary will
work, but this means it never gets updated as contrib/bmake is, and
similarly we won't rebuild it as and when the configure arguments given
to boot-strap change. Whilst the former isn't necessarily a huge problem
given WANT_MAKE_VERSION rarely gets bumped in Makefile, having fewer
variables is a good thing, and so it's easiest if we just always keep it
up-to-date rather than trying to do something similar to what's already
in Makefile (which may or may not be accurate, given updating FreeBSD
gives you an updated bmake, but nothing does so for our bootstrapped
bmake on non-FreeBSD). The latter is more problematic, though, and the
next commit will be changing this configuration.
We thus now add in two checks. The first is to compare MAKE_VERSION
against _MAKE_VERSION from contrib/bmake/VERSION. The second is to
record at bootstrap time the exact configuration used, and compare that
against what we would bootstrap with.
Reviewed by: arichardson, sjg
Differential Revision: https://reviews.freebsd.org/D41556
Add checks that the device ID is supported by the hardware and is
within the range allocated when the driver attaches.
Reviewed by: gallatin, imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41554
Add a message under bootverbose when we find a gicv3 its table type
that is unknown.
Reviewed by: gallatin, imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41553
The GITS_BASER esize field is read-only, there is no need to change it.
Reviewed by: gallatin, imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41552
We don't always know the size of the register set at compile time,
e.g. on arm64 the size of the SVE registers need to be queried on boot.
To support register sets that needs to be calculated at run time
query the correct size when it is zero.
Reviewed by: markj, kib (earlier version)
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41302
Add checks that the device ID is supported by the hardware and is
within the range allocated when the driver attaches.
Reviewed by: gallatin, imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41551
Add a message under bootverbose when we find a gicv3 its table type
that is unknown.
Reviewed by: gallatin, imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41551
The GITS_BASER esize field is read-only, there is no need to change it.
Reviewed by: gallatin, imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41551
When adding indirect (2 level) tabled we will need to know the page
size to calculate the size of the level 1 table. To allow for this find
the page size before entering the loop to calculate the final register
value.
Reviewed by: gallatin, imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41551
Code for pre-11 FreeBSD versions is removed.
Also removed are macros that are not used anymore and "i" variable
does not shadow anymore other "i" variable.
Differential Revision: https://reviews.freebsd.org/D41547
Approved by: erj
In commit c7cffd65c5 the function ether_8021q_frame() was slightly
refactored to use pointer of struct ether_8021q_tag as parameter qtag to
include the new option proto.
It is wrong to write to qtag->pcp as it will effectively change the memory
that qtag points to. Unfortunately the transmit routine of if_vlan parses
pointer of the member ifv_qtag of its softc which stores vlan interface's
PCP internally, when transmitting mbufs that contains PCP the vlan
interface's PCP will get overwritten.
Fix by operating on a local copy of qtag->pcp. Also mark 'struct ether_8021q_tag'
as const so that compilers can pick up such kind of bug.
PR: 273304
Reviewed by: kp
Fixes: c7cffd65c5 Add support for stacked VLANs (IEEE 802.1ad, AKA Q-in-Q)
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D39505
When handling a SHUTDOWN or SHUTDOWN ACK chunk detect if the peer
is violating the protocol by not having made sure all user messages
are reveived by the peer. If this situation is detected, abort the
association.
MFC after: 1 week
Like other dwc3 controller, on Xilinx ZynqMP the base node is just here
to provide resets, the main dwc3 controller node is a child node.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Right now we have to zero-initialize most fields in the varius callers,
but this is a little error prone. Simplify it by zeroing it out upon
allocation instead, drop the other redundant initialization.
Reviewed by: markj
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D41546
In 693f88c9da ("iconv_std: complete the //IGNORE support"), we
more completely implemented //IGNORE, which changed the semantics of
ci_discard_ilseq. DISCARD_ILSEQ semantics are supposed to match
//IGNORE, so we really can't do much about that particular
incompatibility. This broke c*rtomb and mbrtoc* handling of invalid
sequences, but it turns out they don't want DISCARD_ILSEQ semantics at
all; they really want the subset that we call
_CITRUS_ICONV_F_HIDE_INVALID.
This restores the exact flow in iconv_std to precisely how it happened
prior to 693f88c9da.
PR: 265871
Fixes: 693f88c9da ("iconv_std: complete the //IGNORE support")
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D41513
This is an attempt at clean-room implementation of the Linux'
membarrier(2) syscall. For documentation, you would need to read
both membarrier(2) Linux man page, the comments in Linux
kernel/sched/membarrier.c implementation and possibly look at
actual uses.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D32360
For amd64, i386, arm, and riscv, i.e. all architectures except arm64,
the custom implementation is provided since we maintain the bitmask of
active CPUs anyway.
Arm64 uses somewhat naive iteration over CPUs and match current vmspace'
pmap with the argument. It is not guaranteed that vmspace->pmap is the
same as the active pmap, but the inaccuracy should be toleratable.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D32360
The seq_num among other things is used to assign rq_psn value, which is
a 24-bit identifier. When the seq_num is full 4-byte value, we are
usually receiving: '_ib_modify_qp rq_psn overflow, masking to 24 bits'
warning.
This is burdensome for running rdma traffic with large number of
connections, because the number of logs is growing fast.
Signed-off-by: Bartosz Sobczak <bartosz.sobczak@intel.com>
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
Reviewed by: kib@, erj@
MFC after: 3 days
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D41531
On FreeBSD, ZSTD_ASM_SUPPORTED is defined as 0, but on macOS and Linux
it is defined as 1, yet we don't build any of the assembly sources.
Rather than add them just for bootstrapping on non-FreeBSD, explicitly
define ZSTD_DISABLE_ASM so they're not needed and everything is
consistent.
This fixes building a bootstrap LLVM toolchain on non-FreeBSD amd64 (the
only architecture with assembly available).
Reviewed by: emaste, imp
Differential Revision: https://reviews.freebsd.org/D41543
This target produces a C file not an object file, so using ctfconvert on
it should not be attempted. This keeps it in sync with all other uses of
fw_stub.awk, squashes a warning seen during the build of TEGRA124 on
FreeBSD and avoids the same issue failing the build on non-FreeBSD (such
errors are #ifdef'ed into being warnings on FreeBSD in ctfconvert, which
should be revisited in the future).
Reviewed by: manu
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D41542
Systems that predate 971bac5ace ("kbd: consolidate kb interfaces
(phase one)") cannot build kbdcontrol since kbdelays and kbrates moved
to sys/kbio.h. Moreover, on non-FreeBSD, it requires all kinds of ioctls
and sysctls that are highly FreeBSD-specific to build, but we use it as
a bootstrap tool to generate the keymaps used by some kernels (LINT ones
in particular). Thus, when bootstrapping kbdcontrol, disable everything
that's not needed for that singular use, and use the in-tree kbio.h to
get the definitions of the necessary structures.
This allows KBDMUX_DFLT_KEYMAP, UKBD_DFLT_KEYMAP and ATKBD_DFLT_KEYMAP
to be enabled when building on non-FreeBSD, and thus LINT kernels.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D41541
This change adds struct tcp_info fields corresponding to the following
struct tcpcb ones:
- snd_una
- snd_max
- rcv_numsacks
- rcv_adv
- dupacks
Note that while both tcp_fill_info() and fill_tcp_info_from_tcb() are
extended accordingly, no counterpart of rcv_numsacks is available in
the cxgbe(4) TOE PCB, though.
Sponsored by: NetApp, Inc. (originally)
This function actually only ever reads from the TCP PCB. Consequently,
also make the pointer to its TCP PCB parameter const.
Sponsored by: NetApp, Inc. (originally)
When we receive a packet and remove the encapsulating layer we should
also clear out protocol flags and any mbuf tags.
If we do not we risk confusing firewalls filtering the tunneled packet.
See also: https://redmine.pfsense.org/issues/14682#change-69073
Sponsored by: Rubicon Communications, LLC ("Netgate")
Remove leftover empty leading comments/blank lines that had been
spacers between $FreeBSD$ and the following content in config files
in src/etc.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D41548
The LVM label is stored on any of the first four sectors, and the
PV (physical volume) header is stored within the same sector following
the LVM label. The current implementation does not fully check the
offset of PV header, when attaching a bad formatted LVM PV the kernel
may crash due to out-of-bounds memory read.
PR: 266562
Reviewed by: jhb
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D36773
For backward compatibility, the ACPI tables are loaded into the guest
memory. Windows scans the memory, finds the ACPI tables and uses them.
It ignores the ACPI tables provided by the UEFI. We are patching the
ACPI tables in the guest memory, so that's mostly fine. However, Windows
will break when the ACPI tables become to large or when we add entries
which can't be patched by bhyve. One example of an unpatchable entry, is
a TPM log. The TPM log has to be allocated by the guest firmware. As the
address of the TPM log is unpredictable, bhyve can't assign it in the
memory version of the ACPI tables. Additionally, this makes it
impossible for bhyve to calculate a correct checksum of the table.
By default ACPI tables are still loaded into guest memory for backward
compatibility. The new acpi_tables_in_memory config value can be set to
false to avoid this behaviour.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D39979
Notably, define AES_ASM which is required for any AES acceleration
(OpenSSL 1.0 gated all AES acceleration on OPENSSL_CPUID_OBJ instead).
Enabling this exposed that new assembly files added in OpenSSL 3.0
needed to be included in the build (aes-x86-64.S and aes-586.S). Both
of these files supplant both aes_core.c and aes_cbc.c. The last file
had to be moved out of the MI SRCS line for aes and into each ASM_*
for non-x86.
As part of this I audited the generated configdata.pm for amd64, i386,
and aarch64 and found the following additional discrepecancies that are
fixed here as well:
- Enabled BSAES_ASM on amd64 which requires bsase-x86_64.S
- Enabled WHIRLPOOL_ASM on amd64 (asm sources already built)
- Enabled CMLL_ASM on amd64 and i386 (asm sources already built)
aarch64 had no discreprecancies in configdata.pm, and no *.pl asm
generators were missing for aarch64 in Makefile.asm. I did not check
powerpc or armv7, but for armv7 all of the asm generators seem to be
present in Makefile.asm.
Reported by: gallatin (AES-GCM using plain software on amd64)
Reviewed by: gallatin, ngie, emaste
Differential Revision: https://reviews.freebsd.org/D41539
This only affects amd64 and i386, but in particular includes wrappers
for AES encryption/decryption that gate all of the accelerated AES.
Reviewed by: gallatin, ngie, emaste
Differential Revision: https://reviews.freebsd.org/D41537
