Otherwise the script may permute the order of entries in the file since
find(1) output is not stable.
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D54669
Add a function to all nodes under a config option node. This allows
parsing an arbitrary number of similarly structured configuration
options in a config option group.
Reviewed by: corvink, markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D51551
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
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
These plugins require samplerate.h due to virtual_oss's int.h including
it, but don't use any symbols directly so don't link to the library.
Centralize adding the include path.
Reviewed by: christos
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D54705
general:
- find libsamplerate's headers in the temporary sysroot instead of
digging in the source tree.
- use LIBADD where possible
lib/virtual_oss:
- centralize SHLIBDIR define
- centralize include path for internal headers
- don't try to find libsamplerate directly in .OBJDIR
No functional changes.
Reviewed by: christos
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D54704
In particular, we should provide a hint about mac.conf(5), since libjail
will just use the mac_prepare_type(3) API to provide a reasonably sane
interface for system administrators. Progammers wanting to fetch an
arbitrary MAC label would need to bypass libjail and use jail_get(2)
directly with their own prepared `struct mac`.
Differential Revision: https://reviews.freebsd.org/D54067
MAC label handling is a little special; to avoid being too disruptive,
we allocate a `mac_t *` here for the value so that we can mac_prepare()
or mac_from_text() into. As a result, we need:
- A custom free() handler to avoid leaking the *jp_value
- A custom jailparam_get() handler to mac_prepare() the mac_t and
populate the iove properly, so that the kernel doesn't have to
do something funky like copyin, dereference, copyin again.
- A custom jailparam_set() handler to similarly populate the iovec
properly.
Reviewed by: jamie
Differential Revision: https://reviews.freebsd.org/D53960
Instead of ad-hoc comparisons against the struct type in a few places,
start to abstract out an interface for dealing with struct types. For
now, this just means that we have some special jailparam_import and
jailparam_export handling for the ip addr types, but in the next commit
we'll extend it further to support MAC labels.
Reviewed by: jamie
Differential Revision: https://reviews.freebsd.org/D53959
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
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: 607f11055d
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")
This has moved from a generated file in objdir to the source tree.
Remove the old file and any .depend files that reference it.
Reviewed by: bapt (via IRC)
Fixes: 41ccf82b29 ("libc/aarch64: Use MOPS implementations of memcpy/memmove/memset where availble")
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D54729
Trim white space padding that gets added libxo fields cc and stack when
using -C and -c.
The padding is only visible if you're using multiple stacks or
congestion algorithms.
PR: 292262
MFC after: 5 days
Reviewed by: asomers, tuexen
Approved by: asomers (mentor)
Differential Revision: https://reviews.freebsd.org/D54709
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
Add strtonumx(), a companion to strtonum(3) that preserves its safety
and error-reporting semantics while allowing the caller to specify a
conversion base, similar to the strtol(3) family of functions.
Reviewed by: emaste, kib, ziaee
Obtained from: https://www.illumos.org/issues/15365
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D54270
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
Siva Mahadevan