When in netmap (emulated) mode, wireguard interfaces prepend or strip a
dummy ethernet header when interfacing with netmap. The netmap
application thus sees unencrypted, de-encapsulated frames with a fixed
header.
In this mode, netmap hooks the if_input and if_transmit routines of the
ifnet. Packets from the host TX ring are handled by wg_if_input(),
which simply hands them to the netisr layer; packets which would
otherwise be tunneled are intercepted in wg_output() and placed in the
host RX ring.
The "physical" TX ring is processed by wg_transmit(), which behaves
identically to wg_output() when netmap is not enabled, and packets
appear in the "physical" RX ring by hooking wg_deliver_in().
Reviewed by: vmaffione
MFC after: 1 month
Sponsored by: Klara, Inc.
Sponsored by: Zenarmor
Differential Revision: https://reviews.freebsd.org/D43460
When executing `ifconfig -v` this will lead to stalls for a second per interface due to the timeout being set to a static 10 without a module placed, this patch makes sure this is only allowed once per insertion.
When no legacy serial is found, we may be looking at a non-legacy mmio
serial device mapping, in which case the efi_devpath_name() for name
ConOutDev looks like this:
VenHw(XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX,0090DCFE00000000)/Uart(115200,8,N,1)/VenVt100()
Which should tell the kernel to attach a console to 0xfedc9000
(little endian 64 bit value). The value is stored behind the
VENDOR_DEVICE_PATH struct as a byte stream hence we need to check
if said address is appended behind the node. Also enforce use for
uart by requiring the console speed read from the same device.
There is no scientific process for "rs:2" derivation, but evidence would
indicate that this is the correct setting for existing MMIO EFI consoles.
See also: http://bsdimp.blogspot.com/2018/07/how-to-get-memory-mapped-serial-console.html
In (unknown) situations it seems the i2c bus can have trouble,
while nothing about the current link state has changed, the driver
would react by going into a link down state, and start busylooping
on up to 4 cores. Even if there was a valid link, such spinning
on a cpu by a kernel thread would wreak havoc to existing and
new connections.
This patch does the following:
1. If such a bus failure occurs, we keep the last known link state.
2. Prevent busy looping by implementing the lockmgr() facility to
be able to sleep while the i2c code waits on the i2c ISR. We cap
this with a timeout.
3. Pin the admin queues to the last CPU in the system, to prevent
other scenarios where busy looping might occur from landing on CPU
0, which especially seems to cause a lot of issues.
Given the design constraints both in hardware and in software,
the lockmgr() seems to be the only viable option, even though
FreeBSD explicitly forbids sleeping in callout context, but
fails to explain why this is or offer alternatives.
axgbe: revert allocating admin queues to last CPU
The issue was resolved in 52454a1e5b.
Scheduled threads such as CARP are now no longer pinned to CPU 0, making sure
they always get their time slice even if CPUs are blocked.
Since the I/O expander chip does not do a reset when soft power
cycling, the driver will first turn off all LEDs when initializing,
although no specific routine seems to be called when powering down.
This means that the LEDs will stay on until the driver has booted up,
after which the driver will be in a consistent state.
Initially, RSF (Receive Queue Store and Forward) was disabled for
unknown reasons, but the cut-through mode that's enabled as a result
seems to send 0 length packets up to the DMA when the RX queue is
full.
Since the iflib interface needs axgbe_pci_init() and its phy starting capabilities, no data was passed in its absence.
With the NULL check of the axgbe_miibus we also resort back to an MDIO read as a module might be capable of both
clause 22 and clause 45 methods of communication.
with the move of phy_stop() to if_detach() in d50d4e8cd4, it's better to prevent reconfiguring the phy should the pci_init() callout trigger more than once.
Within the code path of autonegotiation for gigabit SFP modules was a bug, causing
a report of LINK_ERR for cases where an external SFP PHY was present. Fixing this issue
did not resolve to a link however, as it turned out that while autonegotiation interrupts
were happening, it's resulting status cannot be correctly determined in all cases. In these
specific cases we have no other option than to assume a module has negotiated to 1Gbit/s.
PHY-specific configuration has been delegated to the miibus driver, if an external PHY is present.
It's possible that the i2c bus does not recognize a PHY on the first pass, so in all cases we
retry up to a maximum of 5 times during each link poll pass to ensure we didn't miss the presence
of an external PHY.
This commit also addresses link issues on both 100 mbit and 1Gb fiber modules. Not all of these modules
have the correct data set according to SFF-8472, as such we first check for gigabit compliance and
the associated baudrate, otherwise we resort back to determining what type of fiber module is plugged
in by checking the baudrate, cable length and wavelength and setting the MAC speed accordingly.
It is possible for a machine to boot into a state in which the configuration register,
responsible for controlling wether an I/O signal is considered an input or output,
contains randomized values. It was assumed this was programmed by the BIOS.
If I/O is reversed, it's possible for the driver to think an SFPP module has been inserted
when there is none, leading to unrecoverable I2C errors.
The configuration register should contain a state which is determined and provided by the BIOS,
hence no hard-coded values are programmed here.
When trying to use a VLAN device (e.g. "em0.123") with a dot
the library fails to parse the interface correctly. The former
pattern is much too restrictive given that almost all characters
can be coerced into a device name via ifconfig.
Remove the particularly restrictive validation. Some characters
still cannot be used as an interface name as they are used as
delimiters in the syntax, but this allows to be able to use most
of them without an issue.
Submitted by: franco@opnsense.org
Differential Revision: https://reviews.freebsd.org/D42485
Reviewed by: vmaffione
(cherry picked from commit ad874544d9f018bf8eef4053b5ca7b856c4674cb)
Reload is used for service reconfiguration as well
and lacks a NAME_prepend-like mechanism so it makes
sense to extend the NAME_reload hook into this
action.
precmd may use configuration checks and blocks setup
from doing its designated work (e.g. nginx). In moving
the invoke of the setup script in front allows us to
provide custom scripts for config file generation and
fixing prior to precmd checking configuration integrity.
Also introduce _run_rc_setup to separate the launcher
from the main one. Let it run correctly in the case
of restart_precmd and block further execution as
would be the case in start due to the internal plumbing
of restart being split into calling stop and start
afterwards.
PR: https://reviews.freebsd.org/D36259
Based on a patch originally found in m0n0wall, expanded
to IPv6 and aligned with FreeBSD's IP input path.
The limit may not be correctly accounted for on the WAN
interface due to dummynet counting the packet again even
though it was already processed.
The problem here is that there's no proper way to reinject
the packet at the point where it was previously removed
from so we make the assumption that ip input was already
done (including pfil) and more or less directly move to
packet output processing.
While here move the passin label up to take the extra check
but avoiding a second label. Also remove the spurious tag
read for forward check since we don't use it and we should
really trust the mbuf flag.
- Bump BRANCH to RELEASE
- Add the anticipated RELEASE announcement date
- Set a static __FreeBSD_version
Approved by: re (implicit)
Sponsored by: https://www.patreon.com/cperciva
Remove archivers/unzip (now in base) and emulators/linux_base-c7 (old
and unlikely to be useful without other linux packages being installed),
ports-mgmt/portmaster (now largely obsolete and discouraged in favour
of using pkg and binary packages) and x11-drivers/xf86-video-vmware
(questionably useful).
Replace devel/git with devel/git@lite (sufficient for most purposes),
and adjust the "ensure the ports exist to sanitize the list" code to
ignore the @lite part when checking that /usr/ports/devel/git exists.
Add sysutils/seatd and x11-wm/sway for wayland support.
Approved by: re (cperciva)
MFC after: 1 minute
Differential Revision: https://reviews.freebsd.org/D45278
(cherry picked from commit d31ed58b9f9360cecd9acfbd12999190edca6e56)
(cherry picked from commit 0543cdc36a)
Code for pools before version 11 uses dmu_objset_find_dp() to scan
for children datasets/clones. It calls enqueue_clones_cb() and
enqueue_cb() callbacks in parallel from multiple taskq threads.
It ends up bad for scan_ds_queue_insert(), corrupting scn_queue
AVL-tree. Fix it by introducing a mutex to protect those two
scan_ds_queue_insert() calls. All other calls are done from the
sync thread and so serialized.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Brian Atkinson <batkinson@lanl.gov>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored by: iXsystems, Inc.
Closes #16162
PR: 278414
Approved by: re (cperciva)
(cherry picked from commit 49086aa35d987b78dbc3c9ec94814fe338e07164)
(cherry picked from commit 455ce17293)
The functions g_eli_init_uma and g_eli_fini_uma are used to trace
the number of devices in GELI. There is an issue where the g_eli_create
function may fail before g_eli_init_uma is called, however
g_eli_fini_uma is still executed in the fail path. This can
incorrectly decrease the device count to zero, potentially leading to
the UMA pool being freed. Accessing the device after the pool has been
freed causes a system panic.
This commit resolves the issue by ensuring devices count is increassed
eariler.
PR: 278828
Reported by: Andre Albsmeier <mail@fbsd2.e4m.org>
Reviewed by: asomers
MFC after: 3 days
Approved by: re (cperciva)
Differential Revision: https://reviews.freebsd.org/D45225
(cherry picked from commit 4b3141f5d5373989598f9447ab5a9f87e2d1c9fb)
(cherry picked from commit ea5a708625)
MFC After: 1 day
Approved by: re (cperciva)
(cherry picked from commit 48edad2edf6eb7a539e40dad8e1f87e3fa4973fd)
(cherry picked from commit 5601feb720)
When calling dxr_init(), the FIB_ALGO infrastructure may provide a
pointer to a previous dxr instance, which permits reuse of auxiliary
dxr structures, i.e. incremental lookup structure updates. For dxr this
is a crucial feature provided by FIB_ALGO, since dxr incremental updates
are typically several orders of magnitude faster than full lookup table
rebuilds.
However, the auxiliary dxr structure caches a pointer to struct fib_data and
relies upon it for performing incremental updates. Apparently, incremental
rebuild requests from FIB_ALGO, i.e. a calls to dxr_init() with a pointer
old_data set, may (under not yet fully understood circumstances) be invoked
within a different fib_data context than the one cached in the previous
version of dxr auxiliary structures. In such (rare) events, we ignore the
offered old dxr context, and proceed with a full lookup structure rebuild
instead of attempting an incremental one using a fib_data context which
may or may not no longer be valid, and thus lead to a system crash.
PR: 278422
MFC after: 1 week
Approved by: re (cperciva)
(cherry picked from commit 4ab122e8ef127d36d95f874e85600c36c87c8c22)
(cherry picked from commit d6e32525c7)
access(), eaccess() and faccessat() will always dereference
symbolic links.
So add a note in the manual page, that lstat(2) should be
used in the case of symbolic links.
PR: 262895
Reviewed by: gbe, pauamma_gundo.com
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D44890
(cherry picked from commit 421025a274fb5759b3ecc8bdb30b24db830b45ae)
(cherry picked from commit f075b61137)
Approved by: re (cperciva)
User misconfiguration, either tunnel loops, or a large number of
different nested tunnels, can overflow the kernel stack. Prevent that
by using if_tunnel_check_nesting().
PR: 278394
Diagnosed by: markj
Reviewed by: kp
Approved by: re (cperciva)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D45197
(cherry picked from commit 93fbfef0b50354b7a1620822454ef29cd415cb2d)
(cherry picked from commit 3ebd2b1c73)
Previously it was possible for dxr_build() to return with da->fd
unset in case of range_tbl or x_tbl malloc() failures. This
may have led to NULL ptr dereferencing in dxr_change_rib_batch().
Approved by: re (cperciva)
MFC after: 1 week
PR: 278422
(cherry picked from commit 0418d7a090)
In 3bfbb521 the behaviour of ls was changed such that -g was no longer
a noop for compatibility with BSD 4.3, but instead changed the output
of long mode to exclude the owner of the file and display only the
group.
Update how FTPd invokes ls to restore the previous behaviour
Reported-by: Andrew Fengler <andrew.fengler@scaleengine.com>
Reviewed-by: jrtc27, des, imp
Approved by: re (cperciva)
MFC after: 3 days
Sponsored-by: ScaleEngine Inc.
Fixes: 3bfbb521fe ("ls: Improve POSIX compatibility for -g and -n.")
(cherry picked from commit 5af3225e0448be6af7f0312e10d2a1dfbe150c25)
(cherry picked from commit e5fadc41b4)
The current check is never false and if nvlist_unpack() fails, we might
panic later down the road.
PR: 266144
Sponsored by: The FreeBSD Foundation
MFC after: 1 day
Reviewed by: dev_submerge.ch, emaste
Differential Revision: https://reviews.freebsd.org/D45237
(cherry picked from commit 64f4e2db6d19d8ab520903a197fcaa8cc7ab9f9a)
(cherry picked from commit 45feaa73c6)
Approved by: re (cperciva)
