Count input/output packets and bytes on the interface as well, not just
in openvpn-specific counters.
PR: 292464
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
We should free the allocated ASID if smmu_init_cd() fails.
Move the allocation of "domain" to simplify the first error path.
Reported by: Kevin Day <kevin@your.org>
Reviewed by: br
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D54676
On read, these registers' fields return 1 if forwarding of the
corresponding interrupt is enabled, and 0 otherwise. The test in
read_enabler() was inverted.
Reported by: Kevin Day <kevin@your.org>
Reviewed by: andrew
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D54678
- Free the pointer that was returned by the allocator, instead of the
address of the first member. These will be equal in practice, but
it's sketchy and won't work on CHERI with subobject bounds checking.
- Use an anonymous struct, there's no need to name it.
Reviewed by: bz, brooks, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D54673
If the allocation fails we should free the task struct.
While here get rid of a couple of unnecessary assertions.
Reported by: Kevin Day <kevin@your.org>
Reviewed by: emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D54671
After commit 3bd8fab241 ("vfs: Move DEBUG_VFS_LOCKS checks to
INVARIANTS"), this option has no effect. Let's finish the removal.
There are a couple of additional uses in zfs, I will submit a separate
patch upstream for them.
Reviewed by: mckusick, kib
Differential Revision: https://reviews.freebsd.org/D54662
Sometimes the client device needs to manage the IOQ the request goes
to. Expand the interface we have for the request to allow it to be set
for this special use case.
Sponsored by: Netflix
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D54714
This ioctl has been marked as "old" starting with the original KAME export
over 20 years ago and has been hidden under #ifdef _KERNEL since. There
is no software that uses it.
pcie_get_speed_cap() has a hard coded skip of 3 devices at the
beginning. It is either called on a pdev or on a result from
pci_upstream_bridge(). In the latter case skipping another three
devices might get us to acpi0 or nexus, neither of which is a
PCI device still and pci_get_vendor() will panic() on that.
Sponsored by: The FreeBSD Foundation (commit)
GHI: https://github.com/freebsd/drm-kmod/issues/393
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D53862
The LinuxKPI based wireless drivers are currently limited to amd64 and
arm64 (and until cleaned up i386). Adding RISC-V now as we have a
report that iwlwifi(4) works on RISC-V [1]. Factor the LinuxKPI based
wireless drivers out into their own block.
Given RISC-V has no ACPI support yet (though we fixed #includes in
order to keep compiling the drivers without further modifications
where possible) we need to take care of rtw89 which fails to compile
without ACPI enabled. A quick check at the Linux build files indicates
that the depenency is not correctly recorded there either. Disable
compiling rtw89 without ACPI (on RISC-V) for the moment until this is
fixed.
[1] https://mail-archive.freebsd.org/cgi/getmsg.cgi?fetch=5947+0+archive/2026/freebsd-wireless/20260112.freebsd-wireless
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D54693
In order to compile iwlwifi(4), which is reported to work on RISC-V,
include the ACPI headers to avoid adding further FreeBSD-specific #ifdefs
to the driver. With this iwlwifi(4) just compiles on RISC-V (at least
if ACPI support is turned off in the module Makefile).
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D54692
We have reports that iwlwifi(4) works on RISC-V. While we can turn off
full ACPI-specific files easily, intermittent code still relies on the
header files to be present. In order to not need to completely #ifdef
everything out we want to include acpi.h from LinuxKPI and as a result
need this file. With this the iwlwifi(4) code compiles just fine and
will do the right thing (given the functional ACPI parts are disabled/
unavailable).
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: mhorne, emaste
Differential Revision: https://reviews.freebsd.org/D54691
This change extends pf(4) limiters so administrator
can specify action the rule executes when limit is
reached. By default when limit is reached the limiter
overrides action specified by rule to no-match.
If administrator wants to block packet instead then
rule with limiter should be changed to:
pass in from any to any state limiter test (block)
OK dlg@
Obtained from: OpenBSD, sashan <sashan@openbsd.org>, 04394254d9
Sponsored by: Rubicon Communications, LLC ("Netgate")
the code that unwinds state creation when something fails needed
the pf_source variable at the function scope to be set, but this
was masked by a declaration in the scope that sets up the source
limiting. this results in a NULL deref in the unwind code when it
needs to clean up the accounting for a source limiter.
i found it funny that i left this comment for myself in the unwinding
code:
/* who needs KASSERTS when we have NULL derefs */
ok jmatthew@
Obtained from: OpenBSD, dlg <dlg@openbsd.org>, fc9311361f
Sponsored by: Rubicon Communications, LLC ("Netgate")
Those finishing touches were supposed to land
with source/state limiter changes. I failed to
spot them during code review.
OK dlg@
Obtained from: OpenBSD, sashan <sashan@openbsd.org>, 098c19176b
Sponsored by: Rubicon Communications, LLC ("Netgate")
the range checks are not needed because both members
(statelim and sourcelim) are uint8_t, they implicitly
fit desired range <0, 255>. Unbreaks gcc build.
Pointed out by deraadt@
OK deraadt@
Obtained from: OpenBSD, sashan <sashan@openbsd.org>, 3a7be1e428
Sponsored by: Rubicon Communications, LLC ("Netgate")
both source and state limiters can provide constraints on the number
of states that a set of rules can create, and optionally the rate
at which they are created. state limiters have a single limit, but
source limiters apply limits against a source address (or network).
the source address entries are dynamically created and destroyed,
and are also limited.
this started out because i was struggling to understand the source and
state tracking options in pf.conf, and looking at the code made it
worse. it looked like some functionality was missing, and the code also
did some things that surprised me. taking a step back from it, even it
if did work, what is described doesn't work well outside very simple
environments.
the functionality i'm talking about is most of the stuff in the
Stateful Tracking Options section of pf.conf(4).
some of the problems are illustrated one of the simplest options:
the "max number" option that limits the number of states that a
rule is allowed to create:
- wiring limits up to rules is a problem because when you load a
new ruleset the limit is reset, allowing more states to be created
than you intended.
- a single "rule" in pf.conf can expand to multiple rules in the
kernel thanks to things like macro expansion for multiple ports.
"max 1000" on a line in pf.conf could end up being many times
that in effect.
- when a state limit on a rule is reached, the packet is dropped.
this makes it difficult to do other things with the packet, such a
redirect it to a tarpit or another server that replies with an
outage notices or such.
a state limiter solves these problems. the example from the pf.conf.5
change demonstrates this:
An example use case for a state limiter is to restrict the number of
connections allowed to a service that is accessible via multiple
protocols, e.g. a DNS server that can be accessed by both TCP and UDP on
port 53, DNS-over-TLS on TCP port 853, and DNS-over-HTTPS on TCP port 443
can be limited to 1000 concurrent connections:
state limiter "dns-server" id 1 limit 1000
pass in proto { tcp udp } to port domain state limiter "dns-server"
pass in proto tcp to port { 853 443 } state limiter "dns-server"
a single limit across all these protocols can't be implemented with
per rule state limits, and any limits that were applied are reset
if the ruleset is reloaded.
the existing source-track implementation appears to be incomplete,
i could only see code for "source-track global", but not "source-track
rule". source-track global is too heavy and unweildy a hammer, and
source-track rule would suffer the same issues around rule lifetimes
and expansions that the "max number" state tracking config above has.
a slightly expanded example from the pf.conf.5 change for source limiters:
An example use for a source limiter is the mitigation of denial of
service caused by the exhaustion of firewall resources by network or port
scans from outside the network. The states created by any one scanner
from any one source address can be limited to avoid impacting other
sources. Below, up to 10000 IPv4 hosts and IPv6 /64 networks from the
external network are each limited to a maximum of 1000 connections, and
are rate limited to creating 100 states over a 10 second interval:
source limiter "internet" id 1 entries 10000 \
limit 1000 rate 100/10 \
inet6 mask 64
block in on egress
pass in quick on egress source limiter "internet"
pass in on egress proto tcp probability 20% rdr-to $tarpit
the extra bit is if the source limiter doesn't have "space" for the
state, the rule doesn't match and you can fall through to tarpitting
20% of the tcp connections for fun.
i've been using this in anger in production for over 3 years now.
sashan@ has been poking me along (slowly) to get it in a good enough
shape for the tree for a long time. it's been one of those years.
bluhm@ says this doesnt break the regress tests.
ok sashan@
Obtained from: OpenBSD, dlg <dlg@openbsd.org>, 8463cae72e
Sponsored by: Rubicon Communications, LLC ("Netgate")
Add support for the MacBookPro11,5 (Mid 2015, 15-inch with AMD Radeon R9 M370X GPU)
to the Apple SMC driver.
Debug testing revealed this model lacks several SMC keys present on MacBookPro11,4
(IBLC, ICMC, IC2C), that model-specific sensor definitions.
Differential Revision: https://reviews.freebsd.org/D54665
Reviewed by: adrian
The mtw(4) driver works correctly on initial boot, but fails to initialize
the MT7601U WiFi adapter after a warm reboot.
Users must either physically unplug and replug the USB adapter, or perform a
full power cycle to restore functionality, if usb power is always powered
(only a replug works)
The root cause is that warm reboot does not power-cycle USB devices,
leaving the MT7601U in a stale state from the previous session.
The MCU retains its ready flag and the device ignores initialization
commands, resulting in timeout waiting for MCU to initialize errors.
At the OS Level, pinging 1.1.1.1 will work, but the speed will be very
slow. In addition in debug mode, we see thousand of error logs.
This patch addresses the issue by:
* Performing USB re-enumeration on attach to reset the device state
* Detecting when the MCU is already marked ready (stale from previous
session) and forcing a reset of the MCU before loading firmware
* Increasing the firmware load timeout from 3s to 10s to accommodate
slower initialization after reset
* Increasing MCU ready poll attempts from 100 to 300 with longer delays
to handle devices that take longer to become ready after reset
Note: The increase was random, lower value might work.
Test Plan:
Tested on MacBook Pro (late-2015) and a MacMini with MediaTek MT7601U
USB adapter across multiple warm reboot cycles.
With the mac-mini and a another desktop, the issue happens only if
connected via an always powered usb hub port in the monitor.
The laptop don't power cycle it power.
Differential Revision: https://reviews.freebsd.org/D54659
Reviewed by: adrian
VT_SETMODE ioctl currently checks the provided signal numbers with its
own ISSIGVALID macro that uses NSIG (32) as a maximum, although the code
that will actually send the signal in sys/kern/kern_sig.c uses
_SIG_VALID which allows up to _SIG_MAXSIG (128).
This change aligns the vt code with the kernel internals and enables the
use of higher signal numbers so that applications are not limited to
SIGUSR1 and SIGUSR2 for vt release and acquire signals.
Signed-off-by: Quentin Thébault <quentin.thebault@defenso.fr>
Reviewed by: emaste, imp, kevans
Differential Revision: https://reviews.freebsd.org/D53615
Implement STYPE_SUSPEND_TO_IDLE sleep type added in c43473dc9b
("sys/power: Generic sleep types").
This is a prerequisite for the firmware to enter the S0ix states. When
suspending to idle, the system stays in an ACPI S0 state, but the CPUs
are idled and devices are suspended/resumed before and after this as
they would be when entering any other sleep type (except for AWAKE and
POWEROFF).
Factor out do_standby, do_sleep, and add a new do_idle function for
idling the CPU (a future patch will make this an idle loop and not just
a simple cpu_idle() call). In do_idle, SCIs (interrupt 9) are enabled to
allow wake events to break the CPU out of idle.
Record all the steps made instead of just the last one in slp_state,
which allows for more flexible unwinding (will be useful to not have to
goto breakout if the SPMC entry call fails when that is committed).
A lot of this borrows from Ben Widawsky's patch: D17675. The main
functional difference with that patch is that suspend-to-idle is a
wholly separate sleep type in this one as opposed to being an
alternative implementation for s2mem (S3).
Reviewed by: emaste, olce
Approved by: olce
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48734
Function to enable specific IRQ source.
This will be used by the s2idle code to enable just SCIs on x86 to break
the CPU out of idle.
Reviewed by: olce
Approved by: olce
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48734
Creation of enc0 before SI_SUB_PROTO_MC mangles the MLD list as well as
encounters IGMP mutex not initialized yet.
Reported & tested by: mjg
NB: the enc(4) is not a true interface indeed. In a perfect world the
module shall not create a cloner, shall not enter if_attach(), shall not
trigger ifnet_arrival_event, neither shall have any protocol attached to
it. The enc0 exists for two purposes: 1) create a bpf(9) tap; 2) to allow
injection packets in the middle of ipsec(4) processing temporarily
rewriting m_pkthdr.rcvif to point at enc0. While the problem 1 is already
solved with a recent divorce between bpf(9) and ifnet(9), the problem 2 is
harder to solve without breaking packet filter rules that use "via enc0".
This is supposed to be a dtrace_id_t, which is a uint32_t, while id_t is
a uint64_t. sdt.h avoids depending on dtrace.h so we can't use
dtrace_id_t directly.
Bump __FreeBSD_version since the layout of structures in the SDT probe
linker set has changed.
Sponsored by: NetApp, Inc.
Sponsored by: Klara, Inc.
Detect presence of FEAT_MOPS, and enable instruction set and set HWCAP2 flag
if present.
Add handler for MOE exceptions.
Reviewed by: andrew
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D54558
State that the object charge is zero if object->cred == NULL, or equal
to the ptoa(object->size) otherwise.
Besides being much simpler, the transition to use object->size corrects
the architectural issue with the use of object->charge. The split
operations effectively carve the holes in the charged regions, but
single counter cannot properly express it. As result, coalescing
anonymous mappings cannot calculate correctly if the extended mapping
already backed by the existing object is already accounted or not [1].
To properly solve the issue, either we need to start tracking exact
charged regions in the anonymous objects, which has the significant
overhead and complications. Or give up on the slight over-accounting
and charge the whole object unconditionally, as it is done in the patch.
Reported by: mmel, pho [1]
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D54572
When an attempt to increase the swap charge for the ucred failed, we
must forcibly increase the charge to allow the vmspace_destroy()
operation to correctly un-charge the accumulated objects.
Add a swap_reserve_force_by_cred() helper and use it in
vmspace_unshare(), same as it is done in normal fork operations.
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D54572
When one uses SIOCAIFADDR_IN6 to add a v6 address, it's possible to set
the preferred and valid lifetimes of the address. If the address
already exists, this ioctl will recalculate and update the expiry times
based on the provided timestamps.
When adding a new address, the lifetimes are inherited by the prefix as
well, but only if we create a new prefix. If the prefix already exists,
as it will in the case where an address is being updated rather than
being added, we do not touch the prefix lifetimes at all. This means
that the original address lifetime still applies to the route associated
with that prefix, so when the prefix expires, the route goes away.
This behaviour doesn't make a lot of sense: if the admin updates an
address lifetime, we should ensure that the prefix lifetime is updated
too. Make that change, ensuring that we do not shorten the prefix
lifetime, as the prefix might be shared among multiple interface
addresses.
Add a regression test.
Co-authored by: Franco Fichtner <franco@opnsense.org>
Reviewed by: pouria, zlei, ae
MFC after: 2 weeks
Sponsored by: OPNsense
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D54562
Tidy up a bunch of places that have the same duplicated logic. Simplify
callers of in6_init_prefix_ltimes(). No functional change intended.
Reviewed by: pouria, zlei, tuexen, glebius
MFC after: 2 weeks
Sponsored by: OPNsense
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D54561
We do not support EFI boot on i386. Thus:
1. Move (back) 'device vt_efifb' from x86/NOTES to amd64/NOTES.
2. Remove 'device vt_efifb' from i386/MINIMAL.
Reported by: jhb
Fixes: f224591746 ("Add ASMC_DEBUG make option")
Fixes: 67599eef01 ("sys/x86/NOTES: Add vt_efifb")
Sponsored by: The FreeBSD Foundation
Kristof Provost