FreeBSD git weekly: 2026-05-25 to 2026-05-31

By design, mac_do(4) only authorizes credentials change requests if they
are issued by a process spawned from '/usr/bin/mdo'.  The executable
paths feature introduces some flexibility by allowing to change that
path, thus allowing another executable to make requests, and to use
multiple such paths (up to 8 in the current implementation).  Its
purpose is to enable thin jails scenarios where mdo(1) may not be at its
canonical path ('/usr/bin/mdo') and to allow experimenting with other
userland programs leveraging setcred(2).

Configuration of executable paths is per-jail and intentionally works
completely similarly with rules.  It is accessible from within a jail
through the 'security.mac.do.exec_paths' sysctl knob and from outside
a jail through the 'mac.do.exec_paths' jail parameter.

This commit groups the verbatim changes of the following commits that
Kushagra Srivastava, our GSoC 2025 student, created in his GitHub
repository (https://github.com/thesynthax/freebsd-src), branch
'task/exec-paths-refactor':

mac_do(4): Complete refactor of allowed executable paths feature
mac_do(4): Fixed changing security.mac.do.* knobs in inheritance mode
mac_do(4): Debugging rules and exec_paths leak on destroy
mac_do(4): Deep copy rules
mac_do(4): Fixed leak
mac_do(4): fixed various bugs, structs inlined, leaks remain
mac_do(4): MAC/do working in jail, leaks decreased
mac_do(4): MAC/do fixed, works in host and jails, leaks removed
mac_do(4): style

Frozen log for these commits:
https://github.com/OlCe2/freebsd-src/compare/main...14fdc49fb29265fac5d0daf95a13d0dce325c951.
The corresponding pull request is at:
https://github.com/OlCe2/freebsd-src/pull/2.

The GSoC's final state of this code still has a number of problems that
are fixed in subsequent commits.  It is however committed separately to
clearly delineate Kushagra's work.

Reviewed by:    olce (amendments to come, see above)
MFC after:      1 month
Relnotes:       yes
Sponsored by:   Google LLC (GSoC 2025)
Sponsored by:   The FreeBSD Foundation (review, commit)
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

Previously write_fnt_source always returned 0, silently discarding
errors.  Return rv so that errors set vtfontcvt's shell exit
appropriately.

Sponsored by: The FreeBSD Foundation

This is not a big deal since it only iterates once before exiting, but
that's no reason to set a bad example.

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195128
MFC after:      1 week
Reviewed by:    ngie
Differential Revision:  https://reviews.freebsd.org/D57251

Introduces the -z <max_cmp_size> flag, enabling users to set a custom file
size limit for pre-installation change checks and avoiding future hard-coded
limit modifications.

Reviewed by:    glebius
Approved by:    glebius (mentor)
Obtained from:  Fudo Security
MFC after:      2 weeks
Sponsored by:   Fudo Security
Differential Revision:  https://reviews.freebsd.org/D57230

Preserve metadata and prevent redundant disk writes during builds with
the install's -C (compare) flag.

The previous historical comparison limit of 16MB is insufficient for
modern toolchains, frequently choked or bypassed by a large base
components like LLVM/Clang, kernels, Rust apps, and large runtime
libraries.

By leaving matching files alone, install keeps their modification timestamps
intact. make(1) safely ignores those files on subsequent runs.

Base examples: 15.0 amd64 GENERIC kernel - 28MB, clang - 105MB, lldb - 97MB, etc.

Reviewed by:    glebius
Approved by:    glebius (mentor)
Obtained from:  Fudo Security
MFC after:      2 weeks
Sponsored by:   Fudo Security
Differential Revision:  https://reviews.freebsd.org/D57271

MFC after:    1 week
Reviewed by:    ziaee, markj
Differential Revision:  https://reviews.freebsd.org/D57182

Reviewed by:  markj
Differential Revision:  https://reviews.freebsd.org/D56485

Sponsored by: The FreeBSD Foundation

While here, reorder the table.

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295618
MFC after:      1 week
Reviewed by:    olce
Differential Revision:  https://reviews.freebsd.org/D57258

Sponsored by: The FreeBSD Foundation
MFC after:      1 week
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/15

While here, fix the bug of mentioning 'enable' as a possible value for
the 'mac.do' jail parameter whereas it is 'new' instead.

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

Note that we still need to stat directories and the roots.

MFC after:      1 week
Sponsored by:   Klara, Inc.
Reviewed by:    kevans
Differential Revision:  https://reviews.freebsd.org/D57325

Signed-off-by:        Faraz Vahedi <kfv@kfv.io>
Reviewed by:    fuz
MFC after:      1 month
Pull Request:   https://github.com/freebsd/freebsd-src/pull/2203

Align ordering between NAME & SYNOPSIS sections.

Obtained from:  https://github.com/apple-oss-distributions/libc
Sponsored by:   Klara, Inc.

The recent IBS work intruduced a bug on older CPUs where the
IBS handler will be called on NMIs even when IBS is not initialized.
Work around this in the IBS handler by checking to see if ibs_pcpu
is NULL before accessing it.

https://forums.freebsd.org/threads/dell-wyse-7040-thin-client-intel-i5-6500te-built-in-sound-alc255-mini-how-to.102656/

Reported by:    razif (on the forum)
Sponsored by:   The FreeBSD Foundation
MFC after:      1 week

On a suspend request via ioctl(), /dev/acpi (and compatible /dev/apm)
both call acpi_ReqSleepState() instead of directly calling
acpi_EnterSleepState().  The former does more checks, returns success if
the machine is already suspending, and notifies user space (via devd(8))
about the impending suspend.  In other words, it seems to have been
designed for user consumption more than the latter function.

So, use acpi_ReqSleepState() in place of acpi_EnterSleepState() in
acpi_pm_func(), which is ultimately called by power_pm_suspend(), itself
called by power_ioctl().  Other callers of power_pm_suspend() (such as
the console drivers) are also user-facing facilities, so should also
benefit from this change.

Reviewed by:    mhorne, imp
Tested by:      mhorne
MFC after:      2 weeks
Sponsored by:   The FreeBSD Foundation
Differential Revision:  https://reviews.freebsd.org/D57239

Segment descriptor contents are fixed on amd64 and not very interesting
compared to the other values that are displayed.

While here, include both the thread and process details of the current
thread and drop redundant output of the trap number.

Reviewed by:    kib
Differential Revision:  https://reviews.freebsd.org/D56989

Reviewed by:  obiwac, emaste, olce
Sponsored by:   The FreeBSD Foundation
Differential Revision:  https://reviews.freebsd.org/D57232

All other paths that return from the kernel to userspace pop the user
trapframe off of the kernel stack pointer before returning to
userspace in restore_registers.  fork_trampoline was missing this, so
all of the user faults after fork pushed another trapframe leaving a
trapframe's worth of wasted space on the kstack.

This would be fatal after a future change to remove duplicate
initialization of td_frame in cpu_fork() as without this fix each time
a thread was recycled it would "lose" another trapframe's worth of
space.

Reviewed by:    kib, andrew
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/23

Reviewed by:  kib, andrew
Sponsored by:   AFRL, DARPA
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/23

This used to be needed to initialize the pcb pointer when the pcb was
allocated on the kstack.

Reviewed by:    kib
Sponsored by:   AFRL, DARPA
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/23

cpu_thread_alloc() already sets these fields anytime td_kstack changes.

Reviewed by:    kib, andrew (arm changes)
Sponsored by:   AFRL, DARPA
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/23

If XSAVE is being used, the XSAVE header will be overwritten either by
copying it from the parent thread in copy_thread for user threads, or
by a fresh copy from fpu/npx_initialstate on the first use of the FPU
for kernel threads.

Reviewed by:    kib
Sponsored by:   AFRL, DARPA
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/23

Reviewed by:  kib
Sponsored by:   AFRL, DARPA
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/23

Suggested by: kib
Reviewed by:    kib, andrew (arm changes)
Sponsored by:   AFRL, DARPA
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/23

This is similar to commit 5e921ff49ea8bb70506248a4675894729cdad8c2
which moved the pcb for amd64, but a bit different.  arm64's pcb is
much larger (over 1KB!) than amd64's since it still embeds FP
registers.  Moving the pcb out of the kstack frees up that much
additional kstack space.  Unlike amd64 however, embedding the pcb in
struct mdthread is not practical as the resulting struct thread would
grow such that UMA would now store 1 thread per 4k page instead of 2
threads per page.  By using a separate UMA zone for pcbs, 2 struct
threads can continue to fit in a single 4k page, and 3 pcbs can fit in
another 4k page.

Reviewed by:    kib, jrtc27, andrew
Sponsored by:   AFRL, DARPA
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/23

Similar to arm64, riscv's pcb embeds a copy of the floating point
registers and is too large to store directly in struct mdthread as is
done on amd64.  Instead, use a separate UMA zone for pcbs.  riscv's
floating point state is not as large as arm64's, so its pcb is also
somewhat smaller and a single 4k page can hold 6 pcbs.

Reviewed by:    kib, jrtc27
Sponsored by:   AFRL, DARPA
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/23

arm64: Add a comment about HWCAP values

They must be identical to Linux. Document this requirement to allow
userspace to depend on this.

Sponsored by:   Arm Ltd

arm64: Support changing the DMAP memory type

When MTE is enabled we will use the DMAP to manage tags. To be able to
read/write them we need to change the memory attribute to
VM_MEMATTR_TAGGED.

Support changing the DMAP memory type to values known to have
equivalent cache properties.

Sponsored by:   Arm Ltd
Differential Revision:  https://reviews.freebsd.org/D55949

arm64: Manage the MTE state like pointer auth

Add the same group of functions we use to manage pointer authentication
in userspace threads.

Sponsored by:   Arm Ltd
Differential Revision:  https://reviews.freebsd.org/D55951

arm64: Check for MTE tag failures on kernel entry

When entering the kernel from userspace we need to check for MTE tag
failures when using asynchronous MTE. This is done by checking if either
tag fault check types that have asynchronous checks are enabled, and
if so check the register the result is stored. It then sets a flag the
kernel can later use to raise a signal.

Sponsored by:   Arm Ltd
Differential Revision:  https://reviews.freebsd.org/D55952

arm64: Add support for per-page flags

We need to store some extra information about a page, e.g. the state of
the MTE tags. Add a MD flags field to each page.

Sponsored by:   Arm Ltd
Differential Revision:  https://reviews.freebsd.org/D55953

To track which pages have MTE tags. Add a flag field to md_page. We
can then use this in MD code to mark which pages have MTE tags.

Reviewed by:    andrew
Sponsored by:   Arm Ltd
Differential Revision:  https://reviews.freebsd.org/D55954

On a copy-on-write, copy the memory tags from the source pages to the
destination pages so the forked process can continue to use MTE.

Reviewed by:    andrew
Sponsored by:   Arm Ltd
Signed-off-by:  Harry Moulton <harry.moulton@arm.com>
Differential Revision:  https://reviews.freebsd.org/D55955

sound: Expose EQ by default

The dev.pcm.%d.eq* sysctls and mixer "bass" and "treble" controls are
exposed only if hint.pcm.%d.eq is set. However, there is no good reason
why we shouldn't at least expose the controls, and let the user
enable/disable/bypass equalization through the sysctl.

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/15

sound: Retire FEEDEQ_BYPASS

In effect, this is the same as the disable state. There is a comment
that says the bypass state skips EQ altogether, which is what the
disable should be. The disable state according to the comment disables
EQ but keeps the EQ preamp (dev.pcm.%d.eq_preamp), however after testing
it seems that the preamp does not really take effect, because with EQ
disabled, feeder_eq is non existent, so we never execute any EQ code in
the first place.

Make things simpler and clearer and have 2 states; enable and disable,
and do what they should do intuitively.

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/15

sound: Remove dead EQ FEEDEQ_DISABLE code

If EQ is disabled, we never reach those code paths in the first place.

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/15

sound: Retire FEEDEQ_DISABLE

We can do this more efficiently by just using the SD_F_EQ* flags. In
fact, the dev.pcm.%d.eq handler will (un)set SD_F_EQ_ENABLED and this is
what we actually test with when choosing to creating the EQ feeder or
not, so setting the state to FEEDEQ_DISABLE does not really an effect in
the first place.

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/15

sound: Retire EQ states

The SD_F_EQ_ENABLED does the same thing, and is actually what we test
against in order to create the EQ feeder.

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/15

sound: Retire hint.pcm.%d.eq_preamp

It wasn't documented in the first place, but it is easier to just use
the sysctl.

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/15

sound: Update feeder_eq.c LICENSE header

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/15

sound: Retire M_MIXER

Even though harmless, it is not really useful, as there is essentially
only one allocation with M_MIXER.

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/18

sound: Retire mixer_ioctl_channel()

This function never succeeds when it is not called from the same process
that has opened the file descriptor (e.g., mixer(8)). The reason is that
the CHN_FOREACH() loop tries to match the pid of each channel with the
pid of the process performing the ioctl, which will not be the same,
unless it's the same process that both opened the channel and performed
the ioctl.

In the case that the same process opens the channels and performs the
ioctl, however, we still do not need to worry, because mixer_ioctl_cmd()
essentially does the same thing anyway. Additionally, this scenario
should be quite rare, given that most applications do not open both
/dev/dsp* and /dev/mixer*, and in fact, it is actively encouraged by the
official OSSv4 specification not to do that.

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/18

sound: Retire unused hw.snd.vpc_mixer_bypass

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/18

sound: Remove unused "from" mixer_ioctl_cmd() argument

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/18

snd_uaudio: Do not use snd_mixer->lock as mixer_lock

In similar fashion to c234740c9d34 ("snd_uaudio: Do not use
pcm_channel->lock to protect uaudio_chan"), stop this layering
violation, and introduce a snd_uaudio(4)-internal mixer_lock.

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/18

snd_uaudio: Lock usbd_transfer_start() in uaudio_mixer_ctl_set()

This section would be previously locked by sound(4)'s mixer lock (see
e87654db5a09 ("snd_uaudio: Stop using mixer_get_lock()")), but
snd_uaudio(4) no longer uses it. This particular code path was missed
during testing, because my sound card does not reach it.

Fixes:          https://cgit.freebsd.org/src/commit/?id=9a00e0b8ca56 ("snd_uaudio: Do not use snd_mixer->lock as mixer_lock")
Reported by:    netchild
Tested by:      netchild
Sponsored by:   The FreeBSD Foundation
MFC after:      6 days

There is no reason to lock snd_mixer->lock here, since the only thing we
are doing with snd_mixer is to call mix_getdevinfo() and mix_get_dev(),
which are one-line getters, which are needed to eventually call
uaudio_get_child_index_by_dev().

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/18

sound: Remove all remaining uses of mixer_get_lock()

These functions are called from sound(4) through MIXER_SET() in
mixer_set(), but nothing mixer-related is used or needs to be locked in
these cases.

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/18

sound: Retire unused mixer_get_lock()

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/18

sound: Do not lock before destroying snd_mixer->lock

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/18

sound: Retire snd_mixer->enuminfo

Instead of caching this when mix_setrecdevs() is called (which many
drivers never call), calculate it when we need it. After all, it is
quite rare that this structure is used by applications.

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/18

sound: Retire MIXER_SIZE and use correct size in DEFINE_CLASS

I am not sure why this hack was needed, but the size should be
sizeof(struct snd_mixer). Unfortunately, we have to expose snd_mixer,
but it should be better than relying on a hack.

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/18

sound: Update mixer.c LICENSE header

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/18

bcm_sdhci_attach() allocates a DMA channel with bcm_dma_allocate()
before creating the bus_dma tag and map.  If a later initialization
step fails, the common error path releases the interrupt and memory
resources, but leaves the DMA channel allocated.

Call bcm_dma_free() for cleanup, as it already performs the required
internal checks and can therefore be invoked directly.

Signed-off-by:  Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
Reviewed by:    mhorne
MFC after:      3 days
Pull Request:   https://github.com/freebsd/freebsd-src/pull/2241

The Rockchip GPIO controller implements PIC operations for the INTRNG
framework but is missing four masking methods that INTRNG calls during
the filter/ithread handoff: pic_disable_intr, pic_enable_intr,
pic_pre_ithread, pic_post_ithread.

Without them, level-sensitive interrupt sources connected to a
Rockchip GPIO pin re-fire continuously while their ithread runs.  On
a RockPro64 with a FUSB302B Type-C controller (i2c) attached to
gpio1 INT_N, the system enters a ~210 kHz interrupt storm the moment
the fusb302 driver attaches and INT_N goes low.

Two complementary changes:

1. Add the four pic_disable_intr/pic_enable_intr/pic_pre_ithread/
   pic_post_ithread method bodies.  Each toggles the pin's
   RK_GPIO_INTMASK bit so the source is masked during the in-flight
   ithread window and unmasked on return, honouring the generic
   INTRNG mask/unmask sequence.

2. When the GPIO IRQ filter dispatches a pin and finds no consumer
   registered, mask the pin at the controller (INTMASK=1, INTEN=0)
   before continuing.  Level-triggered sources keep asserting until
   acked, so a single stuck pin used to flood the console with
   thousands of "Interrupt pin=N unhandled" lines per second.  The
   mask survives until something re-attaches and re-enables the IRQ
   via the standard pic_enable_intr path.

Affects all level-triggered IRQs on Rockchip GPIO banks; edge-
triggered IRQs were already self-acking and unaffected.

Signed-off-by:  Kyle Crenshaw <B1nc0d3x@gmail.com>
Reviewed by:    mhorne
MFC after:      2 weeks
Pull Request:   https://github.com/freebsd/freebsd-src/pull/2197

No functional change intended.

MFC after:      1 week
Sponsored by:   Klara, Inc.
Sponsored by:   NetApp, Inc.
Reviewed by:    royger
Differential Revision:  https://reviews.freebsd.org/D57269

The check for the extended signature table was backwards, so we always
ignored it.

We should verify that the extended signature table fits within the total
image size.

Reviewed by:    jrm, kib
MFC after:      1 week
Differential Revision:  https://reviews.freebsd.org/D57209

MFC after:    1 week

PR:           https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283315
Tested by:      tuexen
MFC after:      3 days

Reviewed by:  markj
Tested by:      aokblast
Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Differential revision:  https://reviews.freebsd.org/D49566

Introduce pcm_hotswap(), which is responsible for sending devctl
SND/CONN notifications.

There are two user-visible improvements with this patch:

First, in pcm_unregister(), instead of just sending a SND/CONN/NODEV
notification when all devices have detached, we also switch to the new
default device if the previously default one has detached, but there are
more left.

Second, in pcm_register(), if the device happens to also be the new
default device, we hot-swap to it. Additionally, if hw.snd.default_auto
is set to 2, then we will essentially be hot-swapping to the newest
attached device.

The latter is especially useful for laptops like the Framework 16, which
comes with a built-in snd_hda(4) speaker-microphone-only device, and
headphones can work with the Framework Audio Expansion Card, which does
not extend the snd_hda(4) device, but is in fact a separate
snd_uaudio(4) device. To achieve automatic audio redirection between
headphones and speakers in this case, there has to be a way to switch
between different devices. The way the Audio Expansion Card works is by
having snd_uaudio(4) attach to it when the headphones are plugged, and
detach when unplugged, so this patch, along with hw.snd.default_auto=2,
can pick up those attach events and switch automatically. Combined with
the pcm_unregister() update, it becomes possible to switch back and
forth between headphones and speakers.

While here, be more robust and lock around snd_unit reads.

In collaboration with:  jrm
Sponsored by:           The FreeBSD Foundation
MFC after:              1 week

Accessing usb_xfer_queue requires bus lock, we added this missing lock
in here to prevent racing issue.

Reviewed by:    adrian
MFC after:      2 weeks
Sponsored by:   The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57293

Reviewed by:  olce
Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Differential revision:  https://reviews.freebsd.org/D57264

* Add a flag to indicate that an INT_CAUSE should not be cleared
  automatically in the generic handler.  This is to ensure correct
  operation of some INT_CAUSEs that are related to each other and must
  be cleared in a certain order.
* Add decode for many more INT_CAUSE registers.

MFC after:      1 week
Sponsored by:   Chelsio Communications

This change removes the hard-forcing of  PCI_IOV and adds shims to
allow the driver to compile and work when the kernel is missing
PCI_IOV support.

Fixes: https://cgit.freebsd.org/src/commit/?id=7c450d1127c7
Reviewed by: sumit.saxena_broadcom.com
Differential Revision: https://reviews.freebsd.org/D57300
Sponsored by: Netflix

Add the device ID to the usbdevs table in order to be able to use
it in the rtwn/usb driver for the RTL8188EU attachment.

(I adjusted the name to B1 compared to the original submission)

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291839
MFC after:      3 days

ukbd_set_leds_callback() built the SET_REPORT control request with
USETW2(req.wValue, UHID_OUTPUT_REPORT, 0) before the loop that
determines the actual HID report ID from sc_id_numlock,
sc_id_scrolllock, or sc_id_capslock.  The data payload was already
correctly prefixed with the real report ID when id != 0, but the
control request's wValue told the device to set report ID 0, which
does not exist on devices that use non-zero report IDs for LED output.

Apple Internal Keyboard / Trackpad (0x05ac:0x0274) uses report ID 1
for LED output.  The mismatch caused the device to STALL every
SET_REPORT request, so the capslock LED could never be updated.

Move the USETW2 call to after the LED-detection loop so that wValue
carries the correct report ID.

Signed-off-by:  Joshua Rogers <Joshua@Joshua.Hu>
Reviewed by:    wulf
MFC after:      1 week
Pull Request:   https://github.com/freebsd/freebsd-src/pull/2210

Sponsored by: The FreeBSD Foundation
MFC after:      1 week
Differential revision:  https://reviews.freebsd.org/D57038

This commit adds the sapphire rapids CPU model to hwpmc_intel.c,
allowing hwpmc to be used on this CPU family.

Reviewed by:    mhorne
MFC after:      3 days
Sponsored by:   Stormshield
Differential Revision:  https://reviews.freebsd.org/D57263

Sponsored by: The FreeBSD Foundation
MFC after:      1 week

net80211: add some example doxygen inline documents

This isn't supposed to be comprehensive, I want to have examples
for the common doxygen comments:

* describing a struct
* inside a struct - single line before the item
* inside a struct - same line after an item
* inside a struct - multi-line before an item

These build fine with the doxygen build in tools/kerneldoc/subsys/ .

Differential Revision: https://reviews.freebsd.org/D57056

net80211: update/add some VHT doxygen documentation

Add and update some documentation to be picked up by doxygen.

Differential Revision: https://reviews.freebsd.org/D57079

net80211: add initial README.md and PROTOCOL.md

* Add top level README.md, linking to in progress and todo items
* Add an 802.11 protocol overview, with todo items - this is designed
  to provide a basic introduction to 802.11 for people wishing to work
  on net80211 and drivers.
* DEBUG.md - cover the debug API
* DATAPATH_TRANSMIT.md - transmit datapath
* DATAPATH_RECEIVE.md - receive datapath
* PROTOCOL.md - a high level (for values of "high") overview of
  the 802.11 protocol and where it intersects with net80211

Differential Revision: https://reviews.freebsd.org/D56760

Reviewed by: bz, pouria
Fixes: https://cgit.freebsd.org/src/commit/?id=7e5bf68495cc ("netlink: add netlink support")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57234

divert: Define semantics for SO_REUSEPORT_LB on divert sockets

Allow SO_REUSEPORT_LB to be set on divert sockets.  If set, then bind()
will add the socket to a "load-balancing group".  When a divert-to rule
matches a port with an associated group, the corresponding state ID is
used to select a specific socket from the group.  Packets without an
associated state are simply forwarded to the first socket in the group.
For now I only pass a state ID from pf, as I couldn't see a useful
identifier on the ipfw side.

This implementation is simple but has a caveat, that being that if
sockets are added to the group while flows are being processed, the size
of the group will change and this changes the mapping of state IDs to
sockets.  So, to get a consistent mapping, the divert socket application
must bind all of its sockets before any traffic is diverted by the
firewall.

Reviewed by:    glebius
MFC after:      1 month
Sponsored by:   OPNsense
Sponsored by:   Klara, Inc.
Differential Revision:  https://reviews.freebsd.org/D56563

divert: Avoid using atomic_(load|store)_(acq|rel)_16

It's not implemented on some arches.  Use a plain int to count the
number of sockets in a divert lbgroup.

Reported by:    Jenkins
Fixes:          https://cgit.freebsd.org/src/commit/?id=895a0ae67fe2 ("divert: Define semantics for SO_REUSEPORT_LB on divert sockets")

The uninitialized timeval was discovered by the new clang.

ctld: Don't ignore pp/vp values of kernel ports with pp == 0 but vp != 0

Fixes:          https://cgit.freebsd.org/src/commit/?id=c6f1e9b8a412 ("ctld: Simplify XML parsing memory management")
Sponsored by:   Chelsio Communications

ctld: Refactor ioctl port handling

- Normalize ioctl port names when the port name is first added to
  the configuration.  This can catch potential duplicate port names
  sooner and helps with other parts of this change.

- When recognizing existing ioctl ports, always expand the name to
  include the physical and virtual port numbers.  This permits binding
  ioctl/0/0 or ioctl/1/0 to a target, for example.

- When adding physical ports to a target, first check for an existing
  kernel port to reuse.  This handles both ioctl and non-ioctl ports
  and removes the need for the conf::add_port method for ioctl ports
  to check in kports.

- If an existing kport isn't found when adding physical ports, check
  to see if the port name is an ioctl port.  If so, call conf::add_port
  to add an ioctl port.  This add_port method overload is now simpler
  as it always creates a new port.

NB: The kernel_port class handles CTL ports that already existed
before ctld started including existing ioctl ports, whereas the
ioctl_port class handles ioctl ports that are created and completely
managed by ctld.  This was true before this change but is perhaps more
obvious after this change.

Sponsored by:   Chelsio Communications
Differential Revision:  https://reviews.freebsd.org/D57092

ctld: Only check physical port linking in a single configuration context

Commit 969876fcee57 moved struct pport from being per-configuration to
being a "global" object shared across multiple configurations.  As a
result, the check for duplicate ports actually spanned across
configurations, such that reloading a configuration would now think
that existing physical ports were already linked.

The linking field in pport added in the C++-ification (commit
6acc7afa34aa) faithfully replicated this bug (albeit simpler as I had
noticed that the TAILQ links weren't used after the earlier commit).

To restore the desired behavior, remove the linking field from struct
pport entirely and use a local unordered_map in conf::add_pports which
tracks if a given pport is claimed by more than one target.

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293076
Reported by:    Ken J. Thomson <thomsonk@yandex.com>
Fixes:          https://cgit.freebsd.org/src/commit/?id=969876fcee57 ("ctld: parse config file independently of getting kernel info")
Sponsored by:   Chelsio Communications
Differential Revision:  https://reviews.freebsd.org/D57093

The only possible way to exercise in_pcbrehash() is to bind(2) and then
connect(2).  The second branch was a dead code since fdb987bebddf.

Reviewed by:            markj
Differential Revision:  https://reviews.freebsd.org/D57241

This is very similar to IPv4 change 24e5c2ee2a18.  Don't modify inpcb
until we are sure connect(2) will be successful.

Fixes:  https://cgit.freebsd.org/src/commit/?id=0c325f53f16731f608919a4489f96fbbe28d2344

The error messages ctld emits when it finds a port or LUN it did not
create were inconsistent with each other as well as with ctld's other
error messages.

MFC after:      1 week
Sponsored by:   Klara, Inc.
Sponsored by:   NetApp, Inc.
Reviewed by:    jhb
Differential Revision:  https://reviews.freebsd.org/D57270

If the weight value is larger than 8 bits, set it to the maximum.
Also, only send RTA_WEIGHT if its value is not the default.
This reduces message size and matches the behavior of
non-multipath routes.

Reviewed by:    emaste, markj
Differential Revision: https://reviews.freebsd.org/D57266

No functional change.

Reviewed by:    pouria, melifaro
Sponsored by:   The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57349

Reviewed by:  pouria, melifaro
Sponsored by:   The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57332

Commit f34aca55adef ("netlink/route: provide pre-2.6.19 Linux compat shim",
2024-06) fixed the partial fix for net/bird2 on the netlink path by mapping the
legacy 8-bit struct rtmsg::rtm_table field onto the modern 32-bit RTA_TABLE
attribute when the latter is absent.

That fix, however, was only applied to rtnl_handle_newroute. The two sibling
handlers: rtnl_handle_delroute and rtnl_handle_getroute were left looking at
attrs.rta_table directly. They are reachable from exactly the same client
(bird, in its netlink scan path), so any FIB number that fits in 8 bits
silently maps to RT_TABLE_UNSPEC in those handlers.

Reviewed by:    melifaro (previous version)
Approved by:    emaste
MFC after:      1 week
Sponsored by:   Netflix

This has been broken since IPv6 support was added in 2000.  We would
validate the port number (which had to be a port number, but can now
also be a service name) and then ignore it.

MFC after:      1 week
Fixes:          https://cgit.freebsd.org/src/commit/?id=08829865f659 ("IPv6 support for lpr.")
Reviewed by:    markj
Differential Revision:  https://reviews.freebsd.org/D57181

lpd: Drop deprecated -p option

This alias for the -s option has been deprecated since 2002.  Time to
drop it from the documentation.

MFC after:      1 week
Reviewed by:    markj
Differential Revision:  https://reviews.freebsd.org/D57183

lpd: Avoid buffer overflow when sending a job

When forwarding a print job to a remote server, we could overflow the
command buffer if a control or data file had a very long name.

MFC after:      1 week
Reported by:    Joshua Rogers <joshua@joshua.hu>
Reviewed by:    markj
Differential Revision:  https://reviews.freebsd.org/D57184

lpd: Fix issues reported by clang-analyzer

Also, unlink our temporary file if we fail to chmod it.

MFC after:      1 week
Reviewed by:    markj
Differential Revision:  https://reviews.freebsd.org/D57185

bhyve/virtio-scsi: Support for multiple targets

Currently, virtio-scsi supports only one target with 16383 LUNs, which
fits nicely with what CTL provides. It would be useful to support more
than that, multiple targets each with 16383 LUNs.

While this can be useful with CTL by attaching each target to another
CTL target port, this will be necessary to support SCSI passthrough.

The new syntax for configuring targets will look like this:

-s X,virtio-scsi,target=/dev/foo,target=/dev/bar,target=4:/dev/baz

This will create the following configuration nodes:

pci.0.X.0.device=virtio-scsi
pci.0.X.0.target.0=/dev/foo
pci.0.X.0.target.1=/dev/bar
pci.0.X.0.target.4=/dev/baz

The existing configuration syntax is still understood for compatibility:

(1) -s X,virtio-scsi
(2) -s X,virtio-scsi,/dev/foo
(3) -s X,virtio-scsi,dev=/dev/foo

This will create the following configuration nodes:

pci.0.X.0.device=virtio-scsi (1, 2, 3)
pci.0.X.0.target.0=/dev/cam/ctl (1)
pci.0.X.0.target.0=/dev/foo (2, 3)

Reviewed by:    markj
MFC after:      1 month
Differential Revision:  https://reviews.freebsd.org/D53221

bhyve/virtio-scsi: Implement task management functions

Currently, all I/O requests are queued internally, and a number of
threads will pick I/O requests of the queue and send them to CTL with
a synchronous CTL_IO ioctl. On the other hand, TMF requests are sent
to CTL immediately using the same synchronous ioctl.

Besides being unworkable for non-CTL backends such as for SCSI
passthrough, this simple approach may easily run into situations
where a TMF request operating on a particular I/O request is sent
to CTL while it is still on our queue and thus unknown to CTL.
In addition, for target and/or LUN resets we should really clear
our queue and return all outstanding I/O requests with a proper
status.

Reviewed by:    markj
MFC after:      1 month
Differential Revision:  https://reviews.freebsd.org/D53222

bhyve/virtio-scsi: Support multiple backends

In order to support multiple backends for virtio-scsi, we should isolate
the core of virtio-scsi from the backend-specific code. The existing
interface to CTL will become the new "CTL" backend for virtio-scsi.

Care has been taken to keep compatibility with previous configurations:
The first backend linked (CTL) will be the default backend if none is
specified, and it does provide a default configuration if no further
options such as targets are explicitly configured.

Reviewed by:    markj
MFC after:      1 month
Differential Revision:  https://reviews.freebsd.org/D53223

bhyve/virtio-scsi: Make all I/O processing parameters configurable

This includes:
- seg_max, the number of segments allowed in a single command
- {ctl,evt,req}_ringsz, the number of descriptors in a queue
- thr_per_q, the number of processing threads per request queue
- num_queues, the number of request queues

Reviewed by:    markj
MFC after:      1 month
Differential Revision:  https://reviews.freebsd.org/D54073

nanobsd: Use NANO_IMG1NAME

Do not hard-code _.disk.image, use NANO_IMG1NAME instead.

Reviewed by:    imp
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D57040

nanobsd: Get the code size by its partition index

Previously the code was assumed to be on the on the first line of the
_.partitioning file.  Instead, explicitly look up the size by its
partition index to make the parsing order-independent.

The _.partitioning file:

1. First column: starting sector.
2. Second column: size in 512-byte sectors.
3. Third column: partition index.

Get the code size by explicitly selecting when the partition index is 1.

Reviewed by:    imp
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D57216

nanobsd: Remove spurious exit call

Reviewed by:    imp
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D57217

nanobsd: Use rounded sizes for cfg and data slices

Use the calculated (rounded up) cfg and data sizes from the
_.partitioning file, instead of consuming them directly from the global
variables.  We obtain the size of the cfg and data slices by explicitly
searching for index 3 and 4 respectively in the _.partitioning file.

This ensures that the final image has the rounded-up sizes, and not the
raw sizes.

Reviewed by:    imp
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D57219

nanobsd: Account for metadata overhead in code slice

The code slice size (CODE_SIZE) includes 16 sectors reserved for disk
metadata (see bsdlabel(8) offset).  Subtract these 16 sectors from the
total size passed to nano_makefs.

This prevents the generated filesystem from consuming the entire slice
allocation, ensuring there is enough space for the metadata without
overflowing the partition boundary.

Reviewed by:    imp
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D57220

nanobsd: Offset code partition to a track boundary

Ensure the primary and secondary code partitions start at a proper track
boundary by applying a NANO_SECTS offset in bytes.

While track-boundary alignment is largely obsolete on modern storage,
this change maintains compatibility with current images (legacy).  A
future commit will transition to 1 MiB alignment boundaries.

Reviewed by:    imp
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D57221

nanobsd: Explicitly set image size and secsz in mkimg

When building an unprivileged NanoBSD image, explicitly set the desired
image size, by passing --capacity to mkimg in bytes, and the logical
sector size (-S) to 512 bytes.

Reviewed by:    imp
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D57222

nanobsd: Refactor secondary code partition logic

Rearrange the conditional logic for building the secondary code slice
(altroot).

Reviewed by:    imp
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D57223

nanobsd: Fix code image size formatting

mkimg(8) parses sizes using expand_number(3).  It is an error to use "b"
as a suffix.  This is the result of a confusion with makefs(8), which
uses NetBSD's strsuftoll(3).

Reviewed by:    imp
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D57224

nanobsd: Use makefs -R flag to honor rounded sizes

Switch from the min/max size flag (-s) to the round-up flag (-R) when
invoking makefs(8).

Because the partition sizes passed to nano_makefs have already been
rounded up by calculate_partitioning(), using -s can cause makefs to try
to perform sizing adjustments that usually result in failures.

Reviewed by:    imp
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D57225

nanobsd: Adjust the order of the flags in makefs

The order of the flags matter in makefs(8). The -t (type) flag must come
before the -o (options) flag; otherwise, the options are reset.

Move the -t flag before the -o flag and remove the shim function
_xxx_adjust_code_size() that was created to align to the default makefs
FFS values.

It effectively prevented us from generating NanoBSD images using
unprivileged builds with the partitions internally aligned as intended.

Reviewed by:    senguptaangshuman17_gmail.com, imp
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D57226

nanobsd: Register the boot.config file in the metalog

Ensure that the boot.config file gets an entry in the metalog by
tgt_touch()ing it.  If a file is not present in the metalog, it gets
excluded from the final image when using "-U" (unprivileged builds).

MFC after:      2 weeks

Sponsored by: The FreeBSD Foundation
MFC after:      1 week
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/15

This doesn't really matter, as we trust that the installer tarballs are
not malicious, but it doesn't hurt to set these flags.

Reported by: Yuxiang Yang, Yizhou Zhao, Ao Wang, Xuewei Feng, Qi Li, and Ke Xu from Tsinghua University using GLM-5.1 from Z.ai
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57274

rc: virtual_oss: Define some variables in rc.conf

They will now be part of /etc/defaults/rc.conf and be accessible by
sysrc(8).

Fixes:          https://cgit.freebsd.org/src/commit/?id=70e27ecba518 ("virtual_oss: Introduce virtual_oss_default_control_device rc variable")
PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295560
Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Reviewed by:    0mp, jrm
Pull-Reqeust:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/33

rc: virtual_oss: Wait for process to exit

Sometimes virtual_oss processes do not exit immediatelly. If we do not
wait for the processes to fully exit before returning from
virtual_oss_stop(), then the service restart operation might call
virtual_oss_start() too early and fail, because it will think the
service wasn't stopped and is still running.

Reported by:    jrm
Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Reviewed by:    0mp, jrm
Pull-Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/33

rc: virtual_oss: Handle absent pidfile properly

Instead of throwing errors from the programs that use it, print a
warning if the file does not exist.

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Reviewed by:    0mp, jrm
Pull-Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/33

This particular calls swaps the samples and maxchan arguments, which can
cause a buffer overflow in p_ch_chain if maxchan exceeds its bounds
(VMAX_CHAN).

Reported by:    Yuxiang Yang, Yizhou Zhao, Ao Wang, Xuewei Feng, Qi Li, and Ke Xu from Tsinghua University using GLM-5.1 from Z.ai
Sponsored by:   The FreeBSD Foundation
MFC after:      3 days
Reviewed by:    emaste

When saving a coredump, savecore(8) maintains .last symlinks for the
info and vmcore artifacts, but not for the crashinfo text report.

Make crashinfo(8) create the link, pointing at the current
core.txt.<bounds> file.

This makes /var/crash/core.txt.last track the same core dump as
info.last and vmcore.last.

[mhorne: I tweaked the submission, such that the link will be created as
soon as the core.txt.X file is generated; not only after a successful
report has been written.]

Signed-off-by:  Ricardo Branco <rbranco@suse.de>
Reviewed by:    mhorne
MFC after:      1 week
Pull Request:   https://github.com/freebsd/freebsd-src/pull/2199

Restore exporting DISTRIBUTIONS to make it available to other scripts.

Reviewed by:    imp, asomers
Fixes:          https://cgit.freebsd.org/src/commit/?id=dc14ae4217a0 ("bsdinstall: do pkgbase installations with the "script" command")
MFC after:      3 days
Differential Revision:  https://reviews.freebsd.org/D57319

use recommended switch with default case to catch invalid values

Reviewed by:    kevans, adrian
Differential Revision:  https://reviews.freebsd.org/D54759

PR:           https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291867
Reported by:    gavin
Reviewed by:    pouria, melifaro
Sponsored by:   The FreeBSD Foundation
Fixes: https://cgit.freebsd.org/src/commit/?id=c597432e2297 ("route(8): convert to netlink")
Differential Revision: https://reviews.freebsd.org/D57336

stand: compile ia32 EFI loader with -malign-double

The UEFI spec says:
> Structures are aligned on boundaries equal to the largest internal
> datum of the structure and internal data are implicitly padded to
> achieve natural alignment.

Unlike the old Intel EFI toolkit, the EDK2 headers expect ia32 builds to
use -malign-double to achive this.

Make EFI versions of libsa32, liblua32, and ficl32. With the difference
being that they are compiled with -malign-double.

Differential Revision:  https://reviews.freebsd.org/D55385

stand/efi/Makefile: fix build order

Move liblua32efi and ficl32efi before .WAIT, otherwise there's a race
between the interpreter and the loader being built.

Reported by:    kbowling
Discussed with: kevans
Fixes:          https://cgit.freebsd.org/src/commit/?id=d15cc7625dde9bcb6a63ee59cccf14f3b93b15bf

Include `<stdbool.h>` instead of defining a local bool enum.
This avoids duplicating a standard type name and keeps the
source compatible with headers that provide bool as a macro,
or in case of C23 that compilers provide it as keyword.

Signed-off-by:  Faraz Vahedi <kfv@kfv.io>
Reviewed by:    fuz
MFC after:      1 month
Pull Request:   https://github.com/freebsd/freebsd-src/pull/2203

uid_t and gid_t are uint32_t (unsigned 32bit integers).
They are printed as signed integers when calling getfacl
(and other tools using the acl_to_text() libc function).
This causes uid/gids larger than 2G (214783648) to print
as negative numbers
- which causes problem with setfacl since the acl_from_text()
  libc function fails on negative numbers.

Reviewed by:    rmacklem
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D57179

* Check the range of the link count before trying to use it.

* Rewrite the comment explaining what the link count is used for.

MFC after:      1 week
Sponsored by:   Klara, Inc.
Reviewed by:    kevans
Differential Revision:  https://reviews.freebsd.org/D57324

* kqueues is a count but is listed as a size

* pipebuf is a size but is listed as a count

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295623
MFC after:      1 week
Fixes:          https://cgit.freebsd.org/src/commit/?id=a4c04958f526 ("libutil: support RLIMIT_PIPEBUF")
Fixes:          https://cgit.freebsd.org/src/commit/?id=85a0ddfd0b26 ("Add a resource limit for the total...")
Reviewed by:    kib
Differential Revision:  https://reviews.freebsd.org/D57333

`yp_prot.h` has carried a SunRPC-era typedef of `bool` guarded by
`BOOL_DEFINED`, but the header itself does not use it. The YP/RPC
interfaces use `bool_t` for protocol booleans.

Defining `bool` in a public header collides with modern C headers
that provide `bool` as a macro or keyword, such as `<stdbool.h>`
and C23-aware assert handling. Drop the compatibility typedef and
leave `bool` definition to the consumer's language mode.

Signed-off-by:  Faraz Vahedi <kfv@kfv.io>
Reviewed by:    fuz
MFC after:      1 month
Pull Request:   https://github.com/freebsd/freebsd-src/pull/2203

Signed-off-by:        Faraz Vahedi <kfv@kfv.io>
Reviewed by:    fuz
MFC after:      1 month
Pull Request:   https://github.com/freebsd/freebsd-src/pull/2203

Signed-off-by:        Faraz Vahedi <kfv@kfv.io>
Reviewed by:    fuz
MFC after:      1 month
Pull Request:   https://github.com/freebsd/freebsd-src/pull/2203

Signed-off-by:        Faraz Vahedi <kfv@kfv.io>
Reviewed by:    fuz
MFC after:      1 month
Pull Request:   https://github.com/freebsd/freebsd-src/pull/2203

QEMU warns when msize is <= 8192 due to degraded performance.
This change bumps our default msize to 128 KiB, matching the
Linux Kernel v5.15 and newer default. Linux supports even larger values,
but 128 KiB is a sensible default.

We also add a new 'msize' mount option to allow users to override
this value, and we validate it against our maximum supported MTU
(currently fixed by the UMA zone size).

Reviewed by:    markj
MFC after:      1 week
Differential Revision: https://reviews.freebsd.org/D56496

PR:   https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295577
MFC after:      2 weeks

Create a function to check if the BAR retry limit has been reached.
Use this in if_ath_tx instead of a hard-coded value.

I've been meaning to do this for a long time.

Differential Revision: https://reviews.freebsd.org/D57055

This is copied from the check in kern_kill.

Reviewed by:    markj, oshogbo
Sponsored by:   The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57244

Allocating large buffers with M_ZERO adds unnecessary overhead since
the data is immediately overwritten. This change embeds the tc and rc
p9_buffer structs directly into p9_req_t so we only zero the small
metadata headers. The actual data payload is allocated with M_NOWAIT.

Embedding the metadata headers by value also allows the p9fs_buf_zone
UMA items to be sized exactly to P9FS_MTU, ensuring they are nicely
aligned.

This also adds proper error handling to p9_get_request() to handle
UMA allocation failures.

Reviewed by:    markj
MFC after:      1 week
Differential Revision: https://reviews.freebsd.org/D56495

We use the explicit "suspend-to-idle" name now.

Sponsored by:   The FreeBSD Foundation

This function returns a pointer to the top of the kstack.

Reviewed by:    kib, andrew (arm changes)
Sponsored by:   AFRL, DARPA
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/23

Previously this was using CAM_PRIORITY_NONE which tripped over the
assertion added in b4b166b8c46b8.

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293076
Reported by:    Ken J. Thomson <thomsonk@yandex.com>
Reviewed by:    imp
Sponsored by:   Chelsio Communications
Differential Revision:  https://reviews.freebsd.org/D56995

The MD function with MI interface to provide a way to read arbitrary
(canonical) KVA.  amd64 only for now.

Reviewed by:    markj
Tested by:      aokblast
Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Differential revision:  https://reviews.freebsd.org/D49566

This fixes LTP open13, which expects O_PATH mmap() to fail
with EBADF, but FreeBSD returned EACCES.

Signed-off-by:  YAO, Xin <mr.yaoxin@outlook.com>
PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295571
Reviewed by:    kib
Pull-Request:   https://github.com/freebsd/freebsd-src/pull/2233

* Migrate the k->wk_key and k->wk_keylen access to the new crypto methods
  in net80211
* don't use ic_miclen, use the tx/rx mic len methods
* don't use wk_txmic and wk_rxmic, use the tx/rx mic data methods

This is in preparation to support GTK/IGTK keys and > 128 bit keys.

Reviewed by:    bz
Differential Revision:  https://reviews.freebsd.org/D54485

Reviewed by:  markj
Tested by:      Alex S <iwtcex@gmail.com>
Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Differential revision:  https://reviews.freebsd.org/D57294

PR:   https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295629
Reviewed by:    markj
Tested by:      Alex S <iwtcex@gmail.com>
Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Differential revision:  https://reviews.freebsd.org/D57294

MAC/do: Executable paths feature (GSoC 2025's final state)

By design, mac_do(4) only authorizes credentials change requests if they
are issued by a process spawned from '/usr/bin/mdo'.  The executable
paths feature introduces some flexibility by allowing to change that
path, thus allowing another executable to make requests, and to use
multiple such paths (up to 8 in the current implementation).  Its
purpose is to enable thin jails scenarios where mdo(1) may not be at its
canonical path ('/usr/bin/mdo') and to allow experimenting with other
userland programs leveraging setcred(2).

Configuration of executable paths is per-jail and intentionally works
completely similarly with rules.  It is accessible from within a jail
through the 'security.mac.do.exec_paths' sysctl knob and from outside
a jail through the 'mac.do.exec_paths' jail parameter.

This commit groups the verbatim changes of the following commits that
Kushagra Srivastava, our GSoC 2025 student, created in his GitHub
repository (https://github.com/thesynthax/freebsd-src), branch
'task/exec-paths-refactor':

mac_do(4): Complete refactor of allowed executable paths feature
mac_do(4): Fixed changing security.mac.do.* knobs in inheritance mode
mac_do(4): Debugging rules and exec_paths leak on destroy
mac_do(4): Deep copy rules
mac_do(4): Fixed leak
mac_do(4): fixed various bugs, structs inlined, leaks remain
mac_do(4): MAC/do working in jail, leaks decreased
mac_do(4): MAC/do fixed, works in host and jails, leaks removed
mac_do(4): style

Frozen log for these commits:
https://github.com/OlCe2/freebsd-src/compare/main...14fdc49fb29265fac5d0daf95a13d0dce325c951.
The corresponding pull request is at:
https://github.com/OlCe2/freebsd-src/pull/2.

The GSoC's final state of this code still has a number of problems that
are fixed in subsequent commits.  It is however committed separately to
clearly delineate Kushagra's work.

Reviewed by:    olce (amendments to come, see above)
MFC after:      1 month
Relnotes:       yes
Sponsored by:   Google LLC (GSoC 2025)
Sponsored by:   The FreeBSD Foundation (review, commit)
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Make it style(9) compliant again

Fix too long lines, declarations not at head of block, improper
indentation and superfluous whitespace coming from the previous commit
introducing the configurable executable paths feature.

While here, fix some older improper comment formatting.

Reviewed by:    bapt
Fixes:          https://cgit.freebsd.org/src/commit/?id=6c3def74e2de ("MAC/do: Support multiple users and groups as single rule's targets")
Fixes:          https://cgit.freebsd.org/src/commit/?id=9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)")
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

Add Kushagra to account for the commit adding the "executable paths"
feature.

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Fix recently-introduced comments

Reviewed by:    bapt
Fixes:          https://cgit.freebsd.org/src/commit/?id=9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)")
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Expand "conf" to "configuration" in a panic message on INVARIANTS

No functional change.

Reviewed by:    bapt
Fixes:          https://cgit.freebsd.org/src/commit/?id=9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)")
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: check_proc(): Remove a superfluous 'if'

No functional change (intended).

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Document and assert when parse error objects must be built

The invariant is that parse_*() functions must create a parse error
object and return it through their 'parse_error' argument if and only if
they return an error code (non-zero).

Add assertions checking this invariant in various places, and in
particular in the new parse_exec_paths(), to be future proof.

Change the contract of parse_and_set_conf() so that the caller is
required to pass a NULL '*parse_error'.

Remove useless resetting of '*parse_error' to NULL.

While here, remove a test that is always true thanks to this invariant
and that was recently introduced with the "executable paths" feature.

No functional change intended.

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Executable paths: Accept an empty string

This effectively allows to disable mac_do(4) by setting the executable
paths to an empty string, realizing a symmetry with rules to be
leveraged in subsequent commits.

Reviewed by:    bapt
Fixes:          https://cgit.freebsd.org/src/commit/?id=9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)")
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Rename size constants/variables to clear confusion with string lengths

These constants represent buffer sizes in bytes, not string lengths.

While here, move MAX in EXEC_PATHS_MAXLEN at start, like the other
constants.  While here, fix the prefix of the old MAC_RULE_STRING_LEN
accordingly.

No functional change.

Reviewed by:    bapt
Fixes:          https://cgit.freebsd.org/src/commit/?id=8aac90f18aef ("mac_do: add a new MAC/do policy and mdo(1) utility")
Fixes:          https://cgit.freebsd.org/src/commit/?id=9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)")
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: find_conf(): Turn an MPASS() into a KASSERT()

Turn the pre-existing comment into an assertion message, with an update
following the introduction of the "executable paths" feature.

Explain in a comment why this situation cannot happen.

Without INVARIANTS, such a situation would cause an immediate panic()
(NULL is dereferenced in the next iteration of the loop), so leave the
check under INVARIANTS only.

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Move hold_conf() and drop_conf() earlier

This is in preparation for using hold_conf() in find_conf().

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: find_conf(): Return configuration with a true reference

In addition to the applicable configuration, find_conf() was returning
a pointer to the actual jail holding the configuration object, with that
jail's mutex locked in order to ensure liveness of the returned
configuration (if we wouldn't, a concurrent thread modifying the jail's
configuration could destroy this configuration object underneath us).

But:
1. Ensuring configuration stability by owning the holding jail's mutex
   requires callers to either keep that mutex locked for a longer period
   of time than just accessing the corresponding 'struct prison' (in
   general, bad for concurrency with other operations involving jails)
   or to perform an additional dance to acquire a real reference in case
   the jail's mutex, for some reason (in general, LORs or acquiring
   a sleepable lock) must be dropped before use.
2. Most code does not actually need to know which jail holds the
   applicable configuration but for unlocking the jail's mutex.  Having
   to deal with the jail holding the configuration can cause confusion
   about which jail (the current one, or the one holding the
   configuration) must be used (and actually did in the very initial
   version of MAC/do, which had a serious flaw as a consequence).

So, do not keep a lock on the holding jail.  Instead, ensure
configuration stability by always acquiring a true reference from the
start and passing it to the caller.  Those callers not doing the dance
mentioned above now need to free it when finished (but this need
replaces the one to unlock the prison).

Additionally, only return the holding jail if explicitly requested by
the caller.  mac_do_jail_get() is currently the only caller that needs
it, in order to be able to reliably report if the configuration is
inherited.

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Fix releasing a nonexistent reference on configuration parsing error

On parsing error, parse_and_set_conf(), introduced with the recent
"executable paths" feature, has been calling drop_conf() on the
being-built configuration.  However, that configuration structure is
allocated through alloc_conf(), which does not grab a reference.
Calling drop_conf() on it, which releases a reference, is thus
erroneous, and causes the underlying counter to saturate, translating
into a memory leak.

To fix this bug, make alloc_conf() grab a reference on the newly-created
'struct conf', and rename it to new_conf() to be more in line with what
it does.  Keep set_conf() as is, i.e., grabbing an additional reference
on behalf of the jail that is going to hold the configuration.
Consequently, make sure that callers of alloc_conf() unconditionally
drop the reference acquired by the latter before returning (i.e., even
if set_conf() has been called).

While here, since hold_conf() is always used to obtain additional
references on a configuration (new_conf() does not use it, instead
directly setting the use count), add an assertion that it is never used
on a configuration that has no references at all (which indicates that
the configuration has been destroyed).

These changes generally simplify the lifecycle of configurations,
reducing the probability of re-introducing reference mismatches (at the
expense of slightly more reference counting operations, but performance
does not matter here).

Reviewed by:    bapt
Fixes:          https://cgit.freebsd.org/src/commit/?id=9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)")
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Constify clone_rules() and clone_exec_paths()'s source argument

Defensive programming.

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Move static assertions on constants close to their definitions

And document more clearly their purpose.

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Remove superfluous configuration initialization

Configuration objects would be initialized (zeroed, and some
STAILQ_INIT() called) multiple times.  Make sure they are so only once,
and add assertions to check that this is actually the case for functions
that expect it.

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: clone_rules(): Readability improvements, constification

Constify in order to let the compiler check that source and destination
arguments are passed in the proper order in the different calls.

No functional change (intended).

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: parse_and_set_conf(): Obey empty parameters; Add doc

parse_and_set_conf() is meant to be used in all situations when there is
a need to set or modify some jail's MAC/do configuration.  This entails
passing the information of whether some parameter was explicitly
specified.  For example, an administrator setting/modifying jail
parameters may not specify executable paths but only rules, in which
case the executable paths value is copied from the currently-applicable
configuration.  The sysctl(8) knobs case always leverages this feature,
since setting a knob changes one parameter at a time.

Currently, a NULL or empty string argument is treated as a non-specified
parameter.  This causes a bug where disabling MAC/do in a jail does not
actually work because, to this end, parse_and_set_conf() is passed an
empty string which it then interprets as a request to copy the currently
applicable configuration's value, which may well not be empty.

Fix this problem by only treating NULL as a marker for a non-specified
parameter, in accordance with the original design for this function.

While here, write some documentation to explain the interface.  While
here, remove the original herald comment for parse_and_set_rules(),
which was inadvertently pushed apart from the replacing
parse_and_set_conf().

Reviewed by:    bapt
Fixes:          https://cgit.freebsd.org/src/commit/?id=9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)")
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: parse_and_set_conf(): Require the model configuration

This change is a prerequisite for the next change in caller
mac_do_jail_set(), which for semantic correctness needs to rely on
a stable model configuration.

The two other callers already call find_conf() to retrieve the
applicable configuration, so for these a second call to find_conf() can
be saved.

However, this does not fix (actually, makes slightly worse) an atomicity
problem when multiple threads concurrently change some jail's
configuration (or the configuration inherited by a jail), which has
existed since the introduction of executable paths due to being able to
change only rules or executable paths independently (and the possibility
of not specifying them and having them copied from the currently
applicable configuration).  Before tackling it in later commits, we
first focus on fixing the semantics of configuration changes in the very
next patches.

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Fix obsolete wording in a comment ("ascendant" => "ancestor")

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Constify is_null_or_empty()

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Fix the recent logic to set jail parameters, make it more tolerant

The logic introduced in the initial commit for the "executable paths"
feature did not match the specification we discussed in that specifying
an empty value (for rules or executable paths) on "mac.do" being "new"
would be treated as an absence of value and trigger a copy from the
currently applicable configuration, instead of being an override that
deactivates mac_do(4) in the jail.  Fix that by distinguishing both
cases.

More generally, a non-explicitly specified parameter is set to the same
value it has in the currently applicable configuration (that of the
closest ancestor jail that has one; 'prison0' (the host) always has
one), with an exception in the disable case.

On disable (explicit: "mac.do" to "disable", implicit: no parameters
passed, or at least one is empty), now accept parameters with
a non-empty value as long as at least one of them is empty (which alone
is enough to disable mac_do(4)).  If no parameters are passed, both are
copied from the currently applicable configuration; if none of them is
empty, then the rules are emptied to effectively disable mac_do(4) (see
the inline comment as to why this was chosen).

On explicit enable ("mac.do" to "enable"), allow not specifying any of
the rules and executable paths, in which case both are copied from the
currently applicable configuration (consistently with what is done when
only one is missing).  Note that, as mentioned above, not specifying any
of them by default still resolves to disabling mac_do(4) (i.e., on no
explicit "mac.do" parameter).

On (explicit) inheritance, allow specifying non-empty parameters,
provided they match the values we are going to inherit.  This enables
re-applying jail parameters' reported values verbatim to the current
jail (idempotence) or, e.g., to some sibling jail.

(While here, make some existing code easier to read by leveraging
is_null_or_empty().)

Reviewed by:    bapt
Fixes:          https://cgit.freebsd.org/src/commit/?id=9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)")
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Configuration: Fix default values: Remove jail creation method

mac_do_jail_create() would create a default configuration on the
just-created jail, erroneously causing mac_do_jail_set() to then
retrieve it and use it as a model when determining the default values
for not-specified parameters, instead of using the configuration
applicable to the parent jail.

Setting a default configuration in mac_do_jail_create() had been done as
a kind of defensive measure to prevent a created jail not to have
a configuration (effectively making it inherit from an ancestor jail,
which is a security hazard except if explicitly requested).  However,
this measure was never really effective (osd_jail_call(PR_METHOD_CREATE)
in kern_jail_set() calls the PR_PETHOD_CREATE methods in an unspecified
order, and stops at the first error), so we are forced to rely in any
case on the fact that an error in a PR_METHOD_CREATE or PR_METHOD_SET
method leads to stopping the jail creation process (which is the case
today; see kern_jail_set()).

Reviewed by:    bapt
Fixes:          https://cgit.freebsd.org/src/commit/?id=9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)")
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Fix reporting of "mac.do" post-"executable paths"

In mac_do_jail_get(), computation of 'jsys' had not been updated to take
into account executable paths.

Reviewed by:    bapt
Fixes:          https://cgit.freebsd.org/src/commit/?id=9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)")
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Visually separate some file sections

With additional empty lines.

No functional change (intended).

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Allocate only one default configuration

When mac_do(4) is loaded, all jails get the same default configuration
(disabled, with only one allowed executable path: '/usr/bin/mdo').
Share it between all jails instead of creating a separate copy for each.

Reviewed by:    bapt
Fixes:          https://cgit.freebsd.org/src/commit/?id=9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)")
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Comment to explain the main invariant for configurations

Once visible, configuration structures must *never* change.

Spell that out in a comment to help future readers/contributors
understand the design.

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Sequential consistency for configuration retrieval

Since the inception of mac_do(4), find_conf(), used to retrieve the
applicable configuration, has been weakly consistent with respect to
concurrent modifications to configuration inheritance that influence its
result (and it has been sequentially consistent with respect to other
configuration modifications, which the initial executable paths feature
and introduction of implicit parameters broke and which will be fixed in
a subsequent commit).

Indeed, find_conf() climbs the jail tree to find an applicable
configuration, which is not an atomic operation.  It examines the
current jail's configuration pointer for each browsed jail, which does
not prevent concurrent modifications of the configuration pointer for
jails below or above it.  Modifications above the current jail are not
a problem, since if climbing needs to continue (i.e., the current jail
inherits), these modifications will be seen if performed before that
check (and may or may not be seen if performed after that check).
However, modifications below the current jail impair sequential
consistency, because they could be done before other modifications at
the current jail or higher up, and the latter could still be picked up
by the rest of the climb, effectively ignoring that the former should
have blocked the climb earlier, making them look as if they had happened
after for the climbing thread.

As a concrete example of this situation, let's examine a scenario where
some jail A is the parent of some jail B, and B inherits its
configuration from A.  An administrator may want to relax the rules only
for jail A but not B.  To this end, he first copies the current rules on
B over to A and then relaxes the rules on A.  He can intuitively and
reasonably expect that changing B's rules first will prevent A's relaxed
rules to leak to threads in B.  Unfortunately, that is not the case: As
explained in the previous paragraph, there can be a time window where
threads from B can still pick up A's new configuration just after it has
been installed.  This arguably makes changing inheritance in mac_do(4)
in a fully secure fashion almost impossible.

If preserving fine-grained locking of prisons, we could prevent this
problem by having find_conf(), once it has climbed to a non-NULL pointer
(actual, non-inherited configuration), do another climb to check that it
can reach the same configuration on the same jail again.  If the new
climb gives another pointer or jail, it could make it the new candidate
and do a climb check again until the situation stabilizes.  A climb
check detects whether changes in jails below that of the candidate
configuration object happened, catching in particular such changes that
happened before changes to the candidate object.  However, that process
alone would still be subject to ABA problems, and we would additionally
need to tag each prison with some modification timestamp (global, or
local but necessitating allocating memory during the check) to fix them.

In the end, we considered this direction to be unnecessarily complex,
given that configuration changes are to be rare events and most uses
will just be configuration determination.

Consequently, switch protecting jail configurations with a single
read-mostly lock.

While here, adapt set_conf() to accept NULL as the new configuration
object, and have remove_conf() call it, which removes duplicated code.

While here, add a comment explaining why we do not need to take any more
locks when climbing the jail tree.

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Support for atomically modifying configurations

As mentioned in previous commits "MAC/do: parse_and_set_conf(): Require
the model configuration" and "MAC/do: Sequential consistency for
configuration retrieval", the introduction of the "executable path"
feature, more fundamentally, the fact that there is now more than one
per-jail parameter and that parameters can be independently modified or
copied, causes an atomicity problem in case of concurrent accesses to of
a jail's applicable configuration.

Partially modifying a configuration is indeed akin to
a read-modify-write operation, where the read is either to the current
or an inherited configuration.  More precisely, once pointed to by
a jail, a configuration object is immutable, and changing the jail's
configuration means making the jail point to another configuration
object.  To change a jail's configuration, a new configuration object is
thus built, and if only some parameters have been explicitly specified,
those that have not been are set by copying the corresponding values
from an existing configuration object (in case of partial modification
of the existing configuration, from the original configuration object
that is going to be replaced; in case of breakage of inheritance or at
jail creation, from the applicable configuration object, which is on an
ancestor jail).  This process is not immune to concurrent modifications
because nothing prevents changes of configurations between reading
existing values and setting the new configuration.  Thus, some other
thread could change the value of a parameter after a copy of it has been
made into the new object but before that copy is actually installed,
which effectively will erase the other thread's modification.

To avoid this, we introduce support for serializing configuration
changes on a given jail.  To this end, we move the jail climbing process
from find_conf() into find_conf_locked(), and make the former call the
latter in a read-locked section.  Similarly, we isolate setting
a configuration in the new set_conf_locked() function, and make
set_conf() call it inside a write-locked section.  The new *_unlocked()
variants make it possible to prevent any configuration access between
determining and reading an applicable configuration, computing from it
a new configuration object and finally setting it, by holding a write
lock over the whole process (there is a trade-off here, as read-mostly
locks cannot be upgraded), effectively making it atomic and realizing
full sequential consistency of configuration changes.  Also, the
'mac_do_rm' global read-mostly lock is made sleepable so that it can be
write-locked over sysctl_handle*() functions or memory allocations
(eases implementation, at the expense of a potential loss of concurrency
which is most probably irrelevant).

No functional change (intended) at this point.

Reviewed by:    bapt
Fixes:          https://cgit.freebsd.org/src/commit/?id=9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)")
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Serialize installing/modifying some jail's configuration

See the immediately preceding commit for explanations on what this is
fixing.

When setting 'mac.do' to 'inherit' on a jail with 'mac.do.rules' and
'mac.do.exec_paths' also specified in the same call, ensure that the
check that these passed parameters are the same as those to be inherited
is atomic with respect to enabling the inheritance (i.e., removing the
jail's 'struct conf' object).  (See previous commit "MAC/do: Fix the
recent logic to set jail parameters, make it more tolerant" as for why
this check exists.)

Because we currently only modify a single configuration object per
transaction, we introduce the parse_and_commit_conf() wrapper around
parse_and_set_conf() to remove duplicated code that would ensue from
calling the latter directly, namely, releasing the 'mac_do_rwl' lock and
freeing the old configuration object (if any).

Taking the 'mac_do_rwl' lock for writing as a way to freeze all accesses
to mac_do(4) configurations was deemed too thin an operation to be worth
wrapping.

Reviewed by:    bapt (older version)
Fixes:          https://cgit.freebsd.org/src/commit/?id=9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)")
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Do not skip blanks when parsing executable paths

The kind of tolerance we apply to parsing rules, whose format we have
defined, cannot be applied to paths since blank characters are allowed
there.

There is still the limitation that no escape character is currently
supported, and so it is not possible to configure a path having a ':'
character.

Reviewed by:    bapt
Fixes:          https://cgit.freebsd.org/src/commit/?id=9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)")
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Update copyright

Update years for the Foundation.

While here, remove the initial '/*-' which has been useless for a long
time.

While here, add a missing space on bapt@'s copyright line (approved by
him).

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

Some third party software expects these to not conflict. As the MTE
support isn't fully in the tree, and these values aren't in a release
we can renumber them without any backwards compatibility issues.

Sponsored by:   Arm Ltd

It is akin to nanosleep(2) and does not access global namespaces.
It should be permitted in capability mode.

Reviewed by: vangyzen
Fixes: https://cgit.freebsd.org/src/commit/?id=3f8455b0905a ("Add clock_nanosleep()")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57343

that are accepted in the activated image or interpreter.

Requested by:   jhb
Reviewed by:    markj
Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Differential revision:  https://reviews.freebsd.org/D57328

Implement dummy support for PR_SET_VMA with PR_SET_VMA_ANON_NAME in
prctl(2).  This prevents applications from receiving EINVAL when
attempting to name anonymous memory regions.

Shortly before I committed the works from a year ago, jhb added a
function ("is_pci_device") so that the check against the devclass
does not have to be coded in every driver.  Use this instead in main
(and stable/15 in case the works get MFCed).

At the same time this fixes the check (the old one was wrong) as we
attach to the LinuxKPI 802.11 driver, e.g., iwlwifi and thus we need
to check the parent of the parent and not just the parent to be
of the devclass "pci" in the identify bus function.  The was the
first error.  The second was (and this is why it worked) that we
checked for == instead of != and so the wrong check became true again.

Discussed with: jhb
Fixes:          https://cgit.freebsd.org/src/commit/?id=11d69a4558de ("LinuxKPI: 802.11: add support for s/r")
MFC after:      3 days
X-MFC after:    ffcf5e356644 ("pci: Add is_pci_device helper function")
Sponsored by:   The FreeBSD Foundation

Our idr implementation is using a mtx lock which in the past has
already caused problems (613723bac219c).
In order to make it easier to tackle the problem start by factoring
out all the operations related to the idr->lock into macros as we
have often done in other parts of code as well.

Sponsored by:   The FreeBSD Foundation
MFC after:      3 days
Reviewed by:    wulf, emaste
Differential Revision: https://reviews.freebsd.org/D55392

The driver implements the ntsync interface as specified in the Linux
7.0-rc3 document Documentation/userspace-api/ntsync.rst.  Only the
documentation and the userspace tests (Linux'
tools/testing/selftests/drivers/ntsync/ntsync.c) were used for
reference.  When the documentation contradicted the tests, tests
behavior was implemented.

One quirk is that Linux API needs to return an error from ioctl() and to
copyout the modified ioctl() argument.  Our generic ioctl() is not flexible
enough to implement this, so the ntsync_ioctl_copyout() hack allows to
copyout the ioctl parameter directly from the ioctl method, instead of
relying on the ioctl infra.

The FreeBSD port of the tests, that can be compiled both on FreeBSD and
Linux, is available at https://github.com/kostikbel/freebsd-ntsync-test.
The Linux binary compiled with the Linux test harness, cannot be run
under linuxolator due to unimplemented syscalls, but the shims in
freebsd-ntsync-test can be compiled on Linux and resulting Linux/glibc
binary run on linuxolator to test linux compat.

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Differential revision:  https://reviews.freebsd.org/D57038

Sponsored by: The FreeBSD Foundation
MFC after:      1 week
Differential revision:  https://reviews.freebsd.org/D57038

I just tried building with system clang on one of my Linux systems which
happens to be version 19, and these warning suppressions are needed for
that version too: same errors as in the original commit.

Reviewed by:    imp
MFC after:      1 week
Differential Revision: https://reviews.freebsd.org/D56874

Without this change I get various undefined symbol errors when trying to
link llvm-nm and llvm-objcopy during the cross-tools stage.

Test Plan: builds now
Reviewed by:    dim, emaste
MFC after:      1 week
Differential Revision: https://reviews.freebsd.org/D56873

Use execenv=jail to enable this.

MFC after:      1 week

The timestamp_origin test sends an ICMP Timestamp Request (ping -Mt) and parses
the tso/tsr fields out of the reply.
When the sysctl net.inet.icmp.tstamprepl is 0, the kernel silently drops the
request, ping receives no reply, and the sed extraction yields an empty $tso.
The test then fails inside atf_check test -n "$tso" with the unhelpful message

Approved by:    maxim
Sponsored by:   Netflix
Differential Revision:  https://reviews.freebsd.org/D57287

The ACL tests use UIDs and GIDs 41 through 49 and expect them to be
unassigned.  Since GID 43 is now assigned to the audio group, some
tests have begun to fail.

While here, also fix a benign Perl syntax issue in the test runner.

MFC after:      1 week
Reviewed by:    markj
Differential Revision:  https://reviews.freebsd.org/D57297

ptrace_single_step currently returns EOPNOTSUPP on riscv.

This temporarily fixes the following CI failures:
https://ci.freebsd.org/job/FreeBSD-main-riscv64-test/16606/testReport/sys.kern/ptrace_test/ptrace__PT_STEP_with_signal/
https://ci.freebsd.org/job/FreeBSD-main-riscv64-test/16606/testReport/sys.kern/ptrace_test/ptrace__step_siginfo/

Reviewed by:    kib
Approved by:    emaste (mentor)
Differential Revision:  https://reviews.freebsd.org/D57288

MAC/do: Tests: Remove shebang lines

They are automatically added by <bsd.test.mk>.

Reviewed by:    bapt
MFC after:      3 days
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Tests: Fix copyrights

No comma needed after a single year.  Add SPDX.

Reviewed by:    bapt
MFC after:      3 days
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Tests: Declare required programs closer to use

Reviewed by:    bapt
MFC after:      3 days
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Tests: Quote the source directory

In a standard test suite installation, this is not necessary, but be
bullet-proof to custom ones, however improbable.

Reviewed by:    bapt
MFC after:      3 days
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Tests: Add support for exec paths, jail parameters, subjails

And also allow configuration of the mdo(1) executable path.

This commit only contains new or modified infrastructure.  No functional
change intended at this point.

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

MAC/do: Add consistency tests

Test that:
1. Concurrent changes to different parameters on the same jail are
   independent/atomic.
2. Inheritance works.
3. Relaxing only parent jail rules does not leak to a subjail thanks to
   sequential consistency.
4. Sysctl knobs and jail parameters stay consistent.

Some of these tests may be extended in the future with several layers of
jails (there is only a single subjail currently).

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

Test msdos22.sh creates 1000 files with long random names consisting
of only ASCII characters. The mount is performed without -L option,
therefore no use of iconv to convert between character sets.

Test msdos23.sh mixes some non-ASCII characters into the file names.
The file system is therefore mounted with -L C.UTF-8 to include tests
of the conversions between UTF-8 and UTF-16.

Test msdos24.sh adds emojis to the names to test the (not yet
committed) support of UTF-16 surrogate pairs in filenames.

All 3 tests succeed with a small number of files (e.g., 10), but fail
most of the time when testing with 1000 files.

The tests have been added to all.exclude since they are expected to
fail. They shall be enabled as regression tests, when the msdosfs code
has been fixed.

MFC after:    1 week
Sponsored by:   Klara, Inc.
Reviewed by:    kevans
Differential Revision:  https://reviews.freebsd.org/D57323

The previously committed versions of these tests failed to prevent
duplicate file names in the list of files to process, leading to
missing files when a "mv" commando tried to operate on a file that
had already been renamed.

The test for filenames containing UTF-16 surrogate pairs stays
disabled, since the required kernel changes have not been committed,
yet.

No functional change intended.

MFC after:      1 week
Reviewed by:    markj
Differential Revision:  https://reviews.freebsd.org/D57186

A typo resulted in the wrong argument for a bytewise
comparison that could result in a crash if
the incorrect argument was not a valid pointer.

This patch fixes the argument.

While investigating this, I noticed that the
correct argument was not being filled in as
required, so this patch fixes that, as well.

Somehow, recovery from a NFSv4.1/4.2 server
crash worked during testing, so this was not
detected.  The bug/patch only affects NFS
client mounts using NFSv4.1/4.2.

PR:     https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294925
Reported by:    Jov <amutu@amutu.com>
MFC after:      3 days

- Use $(...) notation instead of legacy backticked `...`
- Use tabs for indentation
- Indent continuation lines with 4 spaces

Reviewed by:    imp
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D57039

Reviewed by:  kib, andrew
Sponsored by:   AFRL, DARPA
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/23

MFC after:    1 week
Reviewed by:    markj
Differential Revision:  https://reviews.freebsd.org/D57298

Release notes at https://www.sqlite.org/releaselog/3_53_1.html.

Obtained from:  https://www.sqlite.org/2026/sqlite-autoconf-3530100.tar.g

Merge commit 'b00eb376e3fb28e738f9370552dae9d92c1fdd76' into sqlite3

When libarchive is compiled with FreeBSD's native iconv instead of
libiconv, as happens with libarchive in the base system, we need to
configure iconv(3) to handle invalid sequences by returning -1, as
iconv_strncat_in_locale() assumes GNU iconv semantics.

This corresponds to upstream PR 3056.

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294577
MFC after:      1 week

Dag-Erling Smørgrav does not like this, but I do not understand why.

This reverts commit 1df431576f99c3cc26dd4ceb1a6eda864cc9f196.

edk2: enable static asserts for *INT64 alignment

The ia32 loader is now built with -malign-double, so these should pass.

Differential Revision:  https://reviews.freebsd.org/D55386

Revert "edk2: enable static asserts for *INT64 alignment"

This fails when using WITH_BEARSSL. It seems like we build the EFI bits
of libsecureboot (which is really just part of libsa in this case), even
when building the BIOS loader. Revert for now to unbreak the build.

This reverts commit 2fa4bdd7f9e99698a6652db405c3165fdcd41c1d.

Reported by: freebsd@walstatt-de.de

assert.h: Remove leading tabs for whitespace consistency

Signed-off-by:  Faraz Vahedi <kfv@kfv.io>
Reviewed by:    fuz
MFC after:      1 month
Pull Request:   https://github.com/freebsd/freebsd-src/pull/2203

assert.h: Revert "Remove leading tabs for whitespace consistency"

This reverts commit 157c184689ea3d7b8b6bd89aff849e94f004aa0e.

As per style(9), a tab goes after #define.  This should not have been
removed.

Reported by:    kib
Fixes:          https://cgit.freebsd.org/src/commit/?id=157c184689ea3d7b8b6bd89aff849e94f004aa0e.
Pull Request:   https://github.com/freebsd/freebsd-src/pull/2203