| Age | Commit message (Collapse) | Author |
|---|
|
The KERN_OPTS:MDEV_ACPI checks are fine for as long as we are building
modules along the kernel. If one wants to just build the module
standalone out of the module directory this would fail.
Add the missing include for kmod.opts.mk (as was done for tcp
in 1319a76179682).
Sponsored by: The FreeBSD Foundation
Reported by: Tassilo Philipp (tphilipp potion-studios.com)
Fixes: f5a77dc8f8df ("improve module Makefile dependency on ACPI")
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D54769
|
|
If APIC is left in somewhat bad state, with some source hot (not masked
and active, e.g. timers after kexec or due to BIOS bug), we get the
interrupt too early.
Reported by: jmg
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D54543
|
|
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D54543
|
|
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D54543
|
|
NB: Rest of ipfw(4) sources get sx.h via vnet.h, which isn't perfect.
|
|
This patch adds support for receive checksum offload for TCP/IPv6
and UDP/IPv6. Since receive checksum offload can't be configured
separately for IPv4 and IPv6, IFCAP_RXCSUM and IFCAP_RXCSUM_IPV6
can't be changed independently.
Reviewed by: Timo Völker
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D54756
|
|
This patch adds support for transmit checksum offload for TCP/IPv6
and UDP/IPv6.
Reviewed by: Timo Völker
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D54754
|
|
- s/vaues/values/
MFC after: 5 days
|
|
- s/vaues/values/
MFC after: 5 days
|
|
No functional change intended.
MFC after: 3 days
|
|
Unfortunately the aq driver is using readl/writel calls instead
of bus space routines.
This broke, well, everything else.
Fixes: c75eff16ef54aaae7b5dc52ed894cc73a855f469
|
|
Add atomic_set/clear_short/char for doing 8-bit and 16-bit operations
more efficiently on "newer" architectures (POWER7 and later).
Piggybacks on b31abc95eb.
|
|
Make the tap database belong to ip_fw_chain, but leave the default "ipfw0"
tap per-vnet. This is only slightly better than keeping the database per-
vnet, as the bpf name space is per-vnet. However, we yet have only single
ipfw chain. Whenever multiple chains will coexist, this needs to be
addressed.
Require the chain lock to make modifications to the database.
Move tap allocation to a later ruleset build stage, when all rule numbers
are known already. This fixes a panic introduced by 3daae1ac1d82.
Fixes: 3daae1ac1d82ecdcd855101bab5206e914b12350
|
|
The lock grab & drop predates epoch(9) introduction to the network
stack and it doesn't provide a true guarantee that all threads that
may use ipfw configuration have finished. Also the lock prevented
from sleepable operations when freeing the rules.
|
|
Initialize pindex in swap_pager_getpages_locked() before the loop
actually calculating it by skipping bogus pages. Compiler is worried
that loop might never assign to it, which actually cannot happen.
Sponsored by: The FreeBSD Foundation
Fixes: d198ad51ea73bbb162336923a387f52b0b1c1f1d
MFC after: 1 week
|
|
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D54633
|
|
Same as vnode_pager_generic_getpages_async(), swap_pager_getpages() must
handle a possibility of the provided page run to include bogus_page on
some positions, when called from sendfile_swapin(). The swap pager is
used for tmpfs vnodes.
In particular, the bogus page must not be used for pindex calculation,
we better not update the flags on it or wait for the flag clearing, and
we must not call vm_page_valid() because the function expects busy page.
This was bisected down to 72ddb6de1028426 (unix: increase
net.local.(stream|seqpacket).(recv|send)space to 64 KiB),
which is somewhat surprising, but apparently reasonable because it
allowed the run of more than one page for page-in from the swap pager,
which now might include valid pages replaced by bogus one.
In collaboration with: pho
Reviewed by: glebius, markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D54713
|
|
Reviewed by: glebius, markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D54713
|
|
Reviewed by: glebius, markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D54713
|
|
Before the "upper half lock" became sleepable the table manipulation code
needed sophisticated workarounds to recover from races, where the lock is
temporarily dropped to do malloc(M_WAITOK). Remove all these workarounds
as they are no longer needed.
Differential Revision: https://reviews.freebsd.org/D54580
|
|
The so called upper half ipfw lock is not used in the forwarding path. It
is used only during configuration changes and servicing system events like
interface arrival/departure or vnet creation. The original code drops the
lock before malloc(M_WAITOK) and then goes into great efforts to recover
from possible races. But the races still exist, e.g. create_table() would
first check for table existence, but then drop the lock. The change also
fixes unlock leak in check_table_space() in a branch that apparently was
never entered.
Changing to a sleepable lock we can reduce a lot of existing complexity
associated with race recovery, and as use the lock to cover other
configuration time allocations, like recently added per-rule bpf(4) taps.
This change doesn't remove much of a race recovery code, to ease bisection
in case of a regression. This will be done in a separate commit. This
change just removes lock drops during configuration events. The only
reduction is removal of get_map(), which is a straightforward reduce to a
simple malloc(9).
The only sleepable context where the lock was acquired was dyn_tick(). The
comment said it is done to prevent parallel execution of
dyn_expire_states(). However, there is proper internal locking in there
and function should be safe to execute in parallel. The real problem is
dyn_expire_states() called via userland to race with dyn_grow_hashtable()
called via dyn_tick(). Protect against this condition with the main chain
lock.
Differential Revision: https://reviews.freebsd.org/D54535
|
|
Otherwise, a forwarding thread may use the interface being detached. This
is a regression from 0d469d23715d, which manifests itself as a reliably
reproducible panic in in6_selecthlim(). Note that there are old bug
reports about such a panic, and I believe this change will not fix them,
as their nature is not due to a screwed up detach sequence, but due to
lack of proper epoch(9) based synchronization between the detach and
forwarding.
Reviewed by: pouria
Reported & tested by: jhibbits
PR: 292162
Fixes: 0d469d23715d690b863787ebfa51529e1f6a9092
Differential Revision: https://reviews.freebsd.org/D54721
|
|
Building the LINT-NOIP kernel on amd64 with clang 21 results in a
-Werror warning similar to:
sys/dev/mxge/if_mxge.c:1846:44: error: variable 'sum' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer]
1846 | cksum_offset, sizeof(sum), (caddr_t)&sum);
| ^~~
Indeed, if both `INET` and `INET6` are undefined, `sum` is never
initialized. Initialize it to zero to silence the warning.
Reviewed by: jhibbits
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D54730
|
|
Since we move to implement Linux's CLOCK_MONOTONIC with CLOCK_UPTIME, we
broke the some timer support for Linux. Fix this by initializing
CLOCK_UPTIME as a posix clock so we can use in that context.
PR: 292496
MFC After: 5 days
Fixes: 108de784513d
Sponsored by: Netflix
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D54746
|
|
Each C file is compiled separately so these functions can't be inlined
except in the file where they are defined. Since these functions aren't
used outside smartpqi_request.c, just do the simple thing and make them
private to that file.
Reported by: gcc
Reviewed by: jrhall
Fixes: c558eca47970 ("smartpqi: update to version 4660.0.2002")
Differential Revision: https://reviews.freebsd.org/D54732
|
|
Increment fe->sent_packets after export9_send().
Previously, NetFlow v9 templates were only re-announced based on
time, ignoring the packet count parameter (`templ_packets`).
PR: 270083
Reviewed by: glebius pouria
Approved by: glebius (mentor)
MFC after: 1 week
Sponsored by: Subcarpathian BSD User Group
|
|
Reviewed by: olce
Approved by: markj (mentor)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D54505
|
|
Reviewed by: olce
Approved by: markj (mentor)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D54551
|
|
When compiling vchiq with clang 21, the following -Werror warning is
produced:
sys/contrib/vchiq/interface/vchiq_arm/vchiq_arm.c:728:27: error: default initialization of an object of type 'VCHIQ_QUEUE_MESSAGE32_T' with const member leaves the object uninitialized [-Werror,-Wdefault-const-init-field-unsafe]
728 | VCHIQ_QUEUE_MESSAGE32_T args32;
| ^
sys/contrib/vchiq/interface/vchiq_arm/vchiq_ioctl.h:151:40: note: member 'elements' declared 'const' here
151 | const /*VCHIQ_ELEMENT_T * */ uint32_t elements;
| ^
While the warning is formally correct, the 'args32' object is
immediately initialized after its declaration. Therefore, suppress the
warning.
MFC after: 3 days
|
|
The bge interface is special with respect to transmit checksumi
offloading. In the default settings, an bge interface announces TXCSUM
capabilities, but only supports TCP/IPv4 and not UDP/IPv4 due to
limitations of some of the NICs. This results in problems when the bge
interface becomes a member of a bridge. Since currently only the
TXCSUM capabilities are synced when a member is added to a bridge and
not the protocol specific capabilities, this can result in a situation
where UDP packets are sent out using a bge interface without having a
correct checksum.
To mitigate this problem, initially don't announce TXCSUM capabilities,
when UDP transmit checksum is disabled. It is still possible to enable
TXCSUM capabilities via ifconfig.
PR: 291420
Reviewed by: Timo Voelker
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D54486
|
|
This allows a MINIMAL kernel to boot in qemu/kvm.
MFC after: 1 week
Sponsored by: Klara, Inc.
Sponsored by: NetApp, Inc.
|
|
If a jumbo payload option is added, the length of the mbuf chain is
increased by 8 but the actual hop-by-hop extension header with the
jumbo playload option is only inserted in the packet if there are
other options. Therefore, adjust optlen to reflect the actual size
of IPv6 extension headers including the hop-by-hop extension header
containing the jumbo payload option.
Reported by: syzbot+73fe316271df473230eb@syzkaller.appspotmail.com
Reviewed by: markj, Timo Voelker
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D54394
|
|
This patch provides two improvements for TCP/IPv4 and UDP/IPv4
transmit checksum offloading:
(1) Use *CIC_SEG instead of *CIC_FULL, since FreeBSD always provides
a pseudo header checksum.
(2) Don't make transmit IPv4 header checksum offloading a prerequisite
for TCP/IPv4 or UDP/IPv4 transmit checksum offloading.
This is the root cause of PR 291696, since right now the epair
interface does not support transmit IPv4 header checksum offloading,
but TCP/IPv4 and UDP/IPv4 transmit checksum offloading.
PR: 291696
Reviewed by: Timo Voelker
Tested by: Marek Benc
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D54395
|
|
|
|
Have it take a `struct mac` and we'll paper over the difference for
jail(8)/jls(8) in libjail(3). The mac_syscalls.h model is taken from
mac_set_proc_*() that were previously done.
Reviewed by: olce
Differential Revision: https://reviews.freebsd.org/D53958
|
|
A future commit to the area will further our jail integration and add
a use for this: the struct mac itself was already copied in as part of
vfs_buildopts(), so we only need to copyin the strings.
We add an explicit flag argument because the jail operation will need to
do it while holding the prison lock.
Reviewed by: olce
Differential Revision: https://reviews.freebsd.org/D53957
|
|
We'll still add an old-fashioned jail param to configure jail MAC
labels, but for testing it's really easy to grab a jaildesc and use
that.
Reviewed by: jamie, olce
Differential Revision: https://reviews.freebsd.org/D53956
|
|
We'll subsequently use this in the MAC framework to get a struct prison
when we already have the struct file in question, rather than an fd.
Reviewed by: jamie, olce
Differential Revision: https://reviews.freebsd.org/D53955
|
|
This adds the following hooks:
- mpo_prison_check_attach: check for subject capability to attach to
a given jail
- mpo_prison_check_create: check for subject capability to create a
jail with the given option set
- mpo_prison_check_get: check for subject capability to fetch the
given parameters for a jail
- mpo_prison_check_set: check for subject capability to set the
given parameters for a jail
- mpo_prison_check_remove: check for subject capability to remove the
jail
check_get wouldn't typically be a privileged operation, but is included
to give MAC policies a wider range of capabilities at a relatively low
cost. We also add two more for the purpose of label propagation:
- mpo_prison_created: surface the creation of a jail so that one can
do propagation to, e.g., the root vnode or any mounts
- mpo_prison_attached: attach an existing process to the jail so that
one can propagate the jail label to the process, as appropriate.
It is unclear if this is preferred vs. having separate associate entry
points for each type of object we might associate. That would split
these up like so:
- prison_created -> prison_associate_vnode
- prison_attached -> prison_associate_proc
Some sample policy ideas that should be feasible to implement with this
set of hooks, in case it's inspiring:
- mac_bomb: policy that allows a poudriere user to construct jails
without root privilege, given a restricted set of jail parameters.
Slap a warning label on it.
- mac_capsule: policy that realizes the capsule idea that I pitched[0]
on -jail@ to create jails that are effectively immutable once
sealed, using these hooks and a label.
Perhaps a silly idea, but a downstream could consider a scenario where
it can implement special jail enumeration using a MAC policy and a
cooperating application that specifies non-parameter options to filter
the results.
[0] https://lists.freebsd.org/archives/freebsd-jail/2025-September/000550.html
Reviewed by: olce (slightly earlier version)
Differential Revision: https://reviews.freebsd.org/D53954
|
|
A last-minute change to the jail MAC entry points in D53954 is going to
pass the jail_[gs]et(2) flags to mac_prison_check_[gs]et() so that a
policy can, e.g., reject or allow a change if the intent is to
immediately attach, or disallow some fetching of dying jails.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D54658
|
|
Reviewed by: olce
Differential Revision: https://reviews.freebsd.org/D53953
|
|
When an NFSv4.n client specifies settings for attributes other
mode during a Open/Create/Exclusive_41, these other attributes
were not being set.
This patch resolves the problem by calling nfsrv_fixsattr()
after the VOP_CREATE() call in nfsvno_open() for this case.
There is no extant NFSv4.n client that currently does this,
as far as I know.
MFC after: 2 weeks
|
|
|
|
The assumption was incorrect, and the current VIMAGE implementation leaves
a possibility for some interfaces still exist in a jail that is going
away.
Fixes: 607f11055d2d421770963162a4d9a99cdd136152
|
|
This simplifies detach/cleanup for drivers that add multiple ACPI ioctls.
Reviewed by: imp
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D54420
|
|
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")
|
|
Fixes: 73c921ef1d44 ("nvme: Add ability to override ioq to put the request on")
|
|
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
|
