If an interface is a bridge member, and a vlan(4) is also created on
that interface, and net.link.bridge.member_ifaddrs=0, then vlan(4)
will never see any incoming frames because bridge doesn't pass them
to the host for processing.
Work around this by checking for locally-addressed frames using the
MAC address of the interface we received the frame on, but only if
the frame has a .1q tag and there's a vlan trunk on the interface.
This behaviour is almost certainly "wrong" and it's not clear if we
really want to support this, but it did work in the past and the
member_ifaddrs change was not supposed to break it, so this restores
the previous behaviour.
PR: 287150
MFC after: 1 week
Reviewed by: kevans, des
Approved by: kevans (mentor), des (mentor)
Differential Revision: https://reviews.freebsd.org/D50623
(cherry picked from commit a5fe142e08)
When adding a new interface to a bridge and allow_llz_overlap=0, which
is the default value, if_bridge checks if the interface has IPv6 link
local addresses assigned, and if it does, it calls in6_ifdetach() to
remove all IPv6 addresses from the interface.
This means it was possible to do this:
% ifconfig bridge1 create inet6 -ifdisabled auto_linklocal up
% ifconfig epair20 create inet6 -ifdisabled auto_linklocal up
% ifconfig bridge1 addm epair20a
... with the result that the link-local address on epair20a would be
removed, then the interface would be added to the bridge.
If member_ifaddrs=0, which is also the default value, this no longer
works:
% ifconfig bridge1 addm epair20a
ifconfig: BRDGADD epair20a: Invalid argument
This is because the member_ifaddrs check runs before allow_llz_overlap
does its thing, and returns EINVAL since the new interface has IP
addresses on it.
To restore the previous behaviour, reverse the order of these two
checks, so the IPv6 addresses are removed before we check whether
the interface has IPv6 addresses.
MFC after: 1 week
Reviewed by: kevans, kp
Approved by: kevans (mentor)
Differential Revision: https://reviews.freebsd.org/D50477
(cherry picked from commit da2dbdc297)
ether_vlanid_t is a type to represent a VLAN ID, for example inside a
.1q tag. since this is specific to Ethernet, put it in net/ethernet.h.
change bridge to use the new type instead of uint{16,32}_t.
Reviewed by: adrian, kp
Differential Revision: https://reviews.freebsd.org/D49836
(cherry picked from commit 96f830456f)
previously these _KERNEL functions were inconsistent, with some having
parameter names and some not. fix this by giving them all names, per
style(9).
Reviewed by: thj, des
Approved by: des (mentor)
Differential Revision: https://reviews.freebsd.org/D50219
(cherry picked from commit 8c7d193e3c)
include <sys/_types.h> for u_char and u_short.
to avoid including <sys/types.h>, remove the caddr_t cast from LLADDR.
we are trying to get rid of caddr_t anyway, and since sdl_data is
already an array of char, the cast is unnecessary. this also makes
LLADDR const-correct, i.e. passing a const sockaddr_dl will return a
const pointer.
Reviewed by: des
Approved by: des (mentor)
Differential Revision: https://reviews.freebsd.org/D50065
(cherry picked from commit 70b5c91857)
add a new typedef in if_vlan_var.h to represent the lowest (1) and
highest (4095) valid VLAN IDs in a .1q tag.
change if_vlan to use DOT1Q_VID_MAX instead of a magic number.
Reviewed by: kp
Differential Revision: https://reviews.freebsd.org/D49837
(cherry picked from commit c594920250)
Adding a temporary workaround for plugging a fw_com upon if_fwip unloading.
Steps to reproduce(needs two hosts connected with firewire):
while true; do
ifconfig fwip0 10.0.0.5 up
fwcontrol -r
ping -c 10.0.0.3
kldunload if_fwip
done
There's a chance that the unloading of if_fwip.ko triggers following warning:
Warning: memory type fw_com leaked memory on destroy (1 allocations, 64 bytes leaked).
commit d79b6b8ec2 (origin/main, origin/HEAD)
(cherry picked from commit 25a5bb7318)
Do not clear the SCTP_ADDR_IFA_UNUSEABLE flag, if it was set due
to the address being deprecated. Also don't declare tentative
addresses as unusable.
While there, cleanup the code.
PR: 230242
(cherry picked from commit 9639de2a6f)
Only call sctp_gather_internal_ifa_flags() for IPv6 addresses and
also compile this code only, when IPv6 is supported.
This fixes the compilation of IPv4 only kernels.
Reported by: bz@
Fixes: 6ab4b0c0df ("sctp: initilize local address flags correctly")
(cherry picked from commit 99c58ad021)
we have to use 'goto out' here rather than 'break' because otherwise
error is set to 0, which means the error is not propagated back to the
caller.
Reviewed by: kp
(cherry picked from commit 1408670c90)
add a new sysctl, net.link.bridge.member_ifaddrs, which defaults to 1.
if it is set to 1, bridge behaviour is unchanged.
if it is set to 0:
- an interface which has AF_INET6 or AF_INET addresses assigned cannot
be added to a bridge.
- an interface in a bridge cannot have an AF_INET6 or AF_INET address
assigned to it.
- the bridge will no longer consider the lladdrs on bridge members to be
local addresses, i.e. frames sent to member lladdrs will not be
processed by the host.
update bridge.4 to document this behaviour, as well as the existing
recommendation that IP addresses should not be configured on bridge
members anyway, even if it currently partially works.
in testing, setting this to 0 on a bridge with 50 member interfaces
improved throughput by 22% (4.61Gb/s -> 5.67Gb/s) across two member
epairs due to eliding the bridge member list walk in GRAB_OUR_PACKETS.
Reviewed by: kp, des
Approved by: des (mentor)
Differential Revision: https://reviews.freebsd.org/D49995
(cherry picked from commit 0a1294f6c6)
if allow.routing is set, the jail can modify the system routing table
even if it's not a VNET jail.
Reviewed by: kevans, des, adrian
Approved by: kevans (mentor), des (mentor)
Differential Revision: https://reviews.freebsd.org/D49843
(cherry picked from commit 3a53fe2cc4)
As in f7174eb2b4 ("netinet: Do not forward or ICMP response to
INADDR_ANY"), the IPv6 stack should avoid sending packets to the
unspecified address. In particular:
- Make sure that we do not forward received packets to the unspecified
address; the check in ip6_input() catches this in the common case, but
after commit 40faf87894 it's possible for a pfil hook to bypass this
check and pass the packet to ip6_forward() using the
PACKET_TAG_IPFORWARD tag.
- Make sure that we do not reflect packets back to the unspecified
address; RFC 4443 section 2.4 states that we must not generate error
messages in response to packets from the unspecified address.
Reviewed by: zlei, glebius
Reported by: Franco Fichtner <franco@opnsense.org>
MFC after: 1 month
Sponsored by: Klara, Inc.
Sponsored by: OPNsense
Differential Revision: https://reviews.freebsd.org/D49339
(cherry picked from commit b7a61e09e4)
We (correctly) NULL out sk and nk before calling pf_return(), but that
function still tried to use them to undo NAT transformations.
Store the old port numbers and use those rather than sk/nk.
This is a partial import of e11dacbf84
(osport/odport), and the missing parts of
bdea9cbcf2.
Direct commit to stable/14.
PR: 287254
We set MNTK_LOOKUP_SHARED on p9fs mounts, but disable shared locking of
vnodes (i.e., LK_SHARED requests are automatically translated to
LK_EXCLUSIVE.
Reviewed by: kib
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D50759
Some implementations of the virtio 9p transport are implemented on
virtio_mmio, e.g. the Arm FVP. Use the correct macro so the driver
attaches when this is the case.
Reviewed by: markj
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D49600
This truncation is mostly harmless today, but fix it anyway to avoid
pain later down the road.
Reviewed by: olce, kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D50417
(partially cherry picked from commit 0d224af399)
REMOVE doesn't work properly in the face of hard links. Use UNLINKAT
instead, which is implemented by qemu and bhyve and lets the client
specify the name being removed.
PR: 282432
Reviewed by: dfr
Differential Revision: https://reviews.freebsd.org/D47438
If, when submitting a request, the virtqueue is full, we sleep until an
interrupt has fired, then restart the request. However, while sleeping
the channel lock is dropped, and in the meantime another thread may have
reset the per-channel SG list, so upon retrying we'd (re)submit whatever
happened to be left over in the previous request.
Fix the problem by rebuilding the SG list after sleeping.
Sponsored by: Klara, Inc.
- Remove superfluous newlines.
- Use bool literals.
- Replace an unneeded SYSINIT with static initialization.
No functional change intended.
Sponsored by: Klara, Inc.
This code is using the vnode after it has been released and causing a
panic when a p9fs shared volume is unmounted. In fact, it seems like it's
just duplicated code left behind from a bad merge.
PR: 279887
Reported by: Michael Dexter
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1323
When the module is loaded on a system running on qemu/kvm the "modern"
virtio infrastructure is used and virtio_read_device_config() will end
up calling vtpci_modern_read_dev_config(). This function cannot read
values of arbitrary sizes and will panic if the p9fs mount tag size is
not supported by it.
Use virtio_read_device_config_array() instead. It was tested on both
bhyve and qemu/kvm.
PR: 280098
Co-authored-by: Mark Peek <mp@FreeBSD.org>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1320
device_attach routines are allowed to sleep, and this routine already
has other M_WAITOK allocations.
Reported by: markj
Reviewed by: markj
Fixes: 1efd69f933 ("p9fs: move NULL check immediately after alloc...")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45721
Mostly copied from smbfs. This driver in its current state has the exact
same issue that prevents the generic putpages implementation from
working.
Sponsored by: https://www.patreon.com/valpackett
Reviewed by: dfr
Differential Revision: https://reviews.freebsd.org/D45639
MFC after: 3 months
The lib9p implementation takes a strict interpretation of the Twalk RPC
call and returns an error for attempts to lookup ".". The workaround is
to fake the lookup locally.
Reviewed by: Val Packett <val@packett.cool>
MFC after: 3 months
This is derived from swills@ fork of the Juniper virtfs with many
changes by me including bug fixes, style improvements, clearer layering
and more consistent logging. The filesystem is renamed to p9fs to better
reflect its function and to prevent possible future confusion with
virtio-fs.
Several updates and fixes from Juniper have been integrated into this
version by Val Packett and these contributions along with the original
Juniper authors are credited below.
To use this with bhyve, add 'virtio_p9fs_load=YES' to loader.conf. The
bhyve virtio-9p device allows access from the guest to files on the host
by mapping a 'sharename' to a host path. It is possible to use p9fs as a
root filesystem by adding this to /boot/loader.conf:
vfs.root.mountfrom="p9fs:sharename"
for non-root filesystems add something like this to /etc/fstab:
sharename /mnt p9fs rw 0 0
In both examples, substitute the share name used on the bhyve command
line.
The 9P filesystem protocol relies on stateful file opens which map
protocol-level FIDs to host file descriptors. The FreeBSD vnode
interface doesn't really support this and we use heuristics to guess the
right FID to use for file operations. This can be confused by privilege
lowering and does not guarantee that the FID created for a given file
open is always used for file operations, even if the calling process is
using the file descriptor from the original open call. Improving this
would involve changes to the vnode interface which is out-of-scope for
this import.
Differential Revision: https://reviews.freebsd.org/D41844
Reviewed by: kib, emaste, dch
MFC after: 3 months
Co-authored-by: Val Packett <val@packett.cool>
Co-authored-by: Ka Ho Ng <kahon@juniper.net>
Co-authored-by: joyu <joyul@juniper.net>
Co-authored-by: Kumara Babu Narayanaswamy <bkumara@juniper.net>
- Bump BRANCH to RELEASE
- Add the anticipated RELEASE announcement date
- Set a static __FreeBSD_version
Approved by: re (implicit)
Sponsored by: Amazon
Several manual pages for releng/14.3 incorrectly claim that features
were first introduced in FreeBSD 15.0.
I discovered these by running:
git checkout origin/releng/14.3
git grep -F '.Fx 15.0'
Approved by: re (cperciva)
MFC After: 3 days
Reviewed by: imp, ziaee
Pull Request: https://github.com/freebsd/freebsd-src/pull/1685
(cherry picked from commit 5b9660caff)
(cherry picked from commit ef4014882ee1413eba75a78f6e307e16123c63d1)
While here, rename all instances of "RealTek" to "Realtek" for
authenticity.
Approved by: re (cperciva)
Reviewed by: imp, lwshu, zaiee
Pull Request: https://github.com/freebsd/freebsd-src/pull/1649
(cherry picked from commit 76ed6f2db3)
(cherry picked from commit f336a04960b608d2caeaf964663c3a8425f31d71)
While here, change applicable uses of "ports" to "adapters" to be more
precise and improve searchability.
This is a 14.3 candate since it affects (positively) the release notes
generated from the hardware secionts.
Approved by: re (cperciva)
MFC After: 3 days
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1663
(cherry picked from commit 794ee43e75)
(cherry picked from commit 827153d21219f76cf006d50af4cdf85f22b75de0)
This allows 'certctl rehash' to do the right thing when ca_root_nss is
installed, instead of linking the entire bundle to the hash of the
first certificate it contains.
MFC after: 3 days
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D42087
(cherry picked from commit a401c8cb26)
certctl: Fix recent regressions.
- If an untrusted certificate is also found in the list of trusted
certificate, issue a warning and skip it, but don't fail.
- Split on -+BEGIN CERTIFICATE-+ instead of "Certificate:" since
that's what we're really looking for.
Also fix a long-standing bug: .crl files are not certificates, so we
should not include them when searching for certificates.
Reported by: madpilot, netchild, tijl
Reviewed by: netchild, allanjude
Differential Revision: https://reviews.freebsd.org/D42276
(cherry picked from commit 87945a0829)
certctl: Convert line endings before inspecting files.
This ensures that certificate files or bundles with DOS or Mac line
endings are recognized as such and handled identically to those with
Unix line endings.
PR: 274952
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D42490
(cherry picked from commit f7d16a627e)
certctl: Revert to symlinks.
Unfortunately tar will not be able to extract base.txz to a system where
/etc and /usr are not on the same filesystem if the certificates are
hard links.
PR: 277828
Reviewed by: mp
Differential Revision: https://reviews.freebsd.org/D44496
(cherry picked from commit 3fed4f0db5)
(cherry picked from commit 9c34a6876a60dc10fda6ad6a0cbe8f99a372aadc)
Approved by: re (cperciva)
When a channel is closed, dsp_close() either calls vchan_destroy() on vchans,
or chn_abort()/chn_flush() on primary channels. However, the problem with this
is that, when closing a vchan, we end up not terminating the stream properly.
The call sequence we are interested in is the following:
vchan_destroy(vchan) -> chn_kill(vchan) -> chn_trigger(vchan) ->
vchan_trigger(vchan) -> chn_notify(parent)
Even though chn_notify() contains codepaths which call chn_abort(parent),
apparently we do not execute any of those codepaths in this case, so the
DMA remains unterminated, hence why we keep seeing the primary
channel(s) being interrupted even once the application has exited:
root@freebsd:~ # sndctl interrupts
dsp0.play.0.interrupts=1139
dsp0.record.0.interrupts=0
root@freebsd:~ # sndctl interrupts
dsp0.play.0.interrupts=1277
dsp0.record.0.interrupts=0
root@freebsd:~ # sndctl interrupts
dsp0.play.0.interrupts=1394
dsp0.record.0.interrupts=0
The only applications that do not have this issue are those (e.g., mpv) that
manually call ioctls which end up calling chn_abort(), like SNDCTL_DSP_HALT, to
abort the channel(s) during shutdown. For all other applications that do not
manually abort the channel(s), we can confirm that chn_abort()/chn_flush(), or
even chn_trigger(PCMTRIG_ABORT) on the parent, doesn't happen during shutdown.
root@freebsd:~ # dtrace -n 'fbt::chn_abort:entry,fbt::chn_flush:entry { printf("%s", args[0]->name); stack(); }'
dtrace: description 'fbt::chn_abort:entry,fbt::chn_flush:entry ' matched 2 probes
dtrace: buffer size lowered to 1m
^C
[...]
root@freebsd:~ # dtrace -n 'fbt::chn_trigger:entry /args[1] == -1/ { printf("%s", args[0]->name); stack(); }'
dtrace: description 'fbt::chn_trigger:entry ' matched 1 probe
dtrace: buffer size lowered to 1m
CPU ID FUNCTION:NAME
0 68037 chn_trigger:entry dsp0.virtual_play.0
sound.ko`chn_kill+0x134
sound.ko`vchan_destroy+0x94
sound.ko`dsp_close+0x39b
kernel`devfs_destroy_cdevpriv+0xab
kernel`devfs_close_f+0x63
kernel`_fdrop+0x1a
kernel`closef+0x1e3
kernel`closefp_impl+0x76
kernel`amd64_syscall+0x151
kernel`0xffffffff8103841b1
To fix this, modify dsp_close() to execute the primary channel case on both
primary and virtual channels. While what we really care about are the
chn_abort()/chn_flush() calls, it shouldn't hurt to call the rest of the
functions on the vchans as well, to avoid complicating things; they get deleted
right below, anyway.
With the patch applied:
root@freebsd:~ # dtrace -n 'fbt::chn_trigger:entry /args[1] == -1/ { printf("%s", args[0]->name); stack(); }'
dtrace: description 'fbt::chn_trigger:entry ' matched 1 probe
dtrace: buffer size lowered to 1m
CPU ID FUNCTION:NAME
1 68037 chn_trigger:entry dsp0.virtual_play.0
sound.ko`chn_flush+0x2a
sound.ko`dsp_close+0x330
kernel`devfs_destroy_cdevpriv+0xab
kernel`devfs_close_f+0x63
kernel`_fdrop+0x1a
kernel`closef+0x1e3
kernel`closefp_impl+0x76
kernel`amd64_syscall+0x151
kernel`0xffffffff8103841b
0 68037 chn_trigger:entry dsp0.play.0
sound.ko`chn_notify+0x4ce
sound.ko`vchan_trigger+0x105
sound.ko`chn_trigger+0xb4
sound.ko`chn_flush+0x2a
sound.ko`dsp_close+0x330
kernel`devfs_destroy_cdevpriv+0xab
kernel`devfs_close_f+0x63
kernel`_fdrop+0x1a
kernel`closef+0x1e3
kernel`closefp_impl+0x76
kernel`amd64_syscall+0x151
kernel`0xffffffff8103841b
Above we can see a chn_trigger(PCMTRIG_ABORT) on the parent (dsp0.play.0),
which is coming from the chn_abort() (inlined) in chn_notify():
root@freebsd:~ # dtrace -n 'kinst::chn_abort:entry { stack(); }'
dtrace: description 'kinst::chn_abort:entry ' matched 5 probes
dtrace: buffer size lowered to 1m
CPU ID FUNCTION:NAME
1 72580 chn_notify:1192
sound.ko`0xffffffff8296cab4
sound.ko`vchan_trigger+0x105
sound.ko`chn_trigger+0xb4
sound.ko`chn_flush+0x2a
sound.ko`dsp_close+0x330
kernel`devfs_destroy_cdevpriv+0xab
kernel`devfs_close_f+0x63
kernel`_fdrop+0x1a
kernel`closef+0x1e3
kernel`closefp_impl+0x76
kernel`amd64_syscall+0x151
kernel`0xffffffff8103841b
We can also confirm the primary channel(s) are not interrupted anymore:
root@freebsd:/mnt/src # sndctl interrupts
dsp0.play.0.interrupts=0
dsp0.record.0.interrupts=0
In collaboration with: adrian
Tested by: adrian, christos, thj
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: thj, adrian, emaste
Differential Revision: https://reviews.freebsd.org/D50488
(cherry picked from commit f6430bc61d)
(cherry picked from commit 0c6aa445ec0c85e7c9653d20562907742569de6f)
Approved by: re (cperciva)
