FreeBSD git weekly: 2026-05-04 to 2026-05-10

The current text fails to draw the reader's attention to the fact that
VIS_SAFE essentially exempts certain characters from being encoded.

While here, fix some markup nits.

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

MFC after:    3 days

MFC after:            1 day
Discussed with:         bcr, ivy, kevans, ngie
Differential Revision:  https://reviews.freebsd.org/D56608

While here, remove empty sections from cam.4.

MFC after:      3 days
Fixes:          https://cgit.freebsd.org/src/commit/?id=1a7151f79664 cam: Add probes for xpt actions

MFC after:    1 week

Update smartpqi(4) to document the dev.smartpqi.<unit>.debug_level
sysctl for runtime debug level changes, and note that device
add/remove and controller event messages always appear in dmesg
regardless of the debug_level setting.

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294161
Reviewed by:    imp
Approved by:    imp
MFC after:      2 weeks

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

PR:   https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292147

Reported by:  ziaee@
Fixes:  https://cgit.freebsd.org/src/commit/?id=fd8d34ce27 ("dpaa: Migrate from NCSW base to a home-grown driver")

Reported by:  ziaee@
Fixes:  https://cgit.freebsd.org/src/commit/?id=d22051b18 ("iicbus/rtc: Add driver for the Ricoh rs5c372 RTC")

Older SMC firmware exposed AUPO as a Wake-on-LAN control. On updated
firmware, the key controls automatic power-on when AC power is restored
after a power loss; WoL is handled by the GBE controller instead.
Rename the sysctl to reflect the current semantics. No compatibility
alias is provided as the sysctl has not appeared in any release.

Reviewed by:    ziaee, adrian
Differential Revision:  https://reviews.freebsd.org/D56747

The LAN8700 / LAN8710 PHYs were Standard Microsystems Corporation (SMSC)
parts.  I presume SMC was chosen as an abbreviation, but the company
always used SMSC as its short name.

SMSC was acquired by Microchip in 2012.  I kept the pre-acquisition
name, as NetBSD (from where we obtained miidevs) uses SMSC.

Reviewed by:    adrian
Sponsored by:   The FreeBSD Foundation
Differential Revision:  https://reviews.freebsd.org/D56819

acpi_panasonic_shutdown() calls hkey_sound_mute() without holding
the ACPI serial lock. Every other call site holds
`ACPI_SERIAL_BEGIN(panasonic)` before calling it, as the locking
model is caller-owned.

This seems to affect the whole Panasonic Toughtbook lineup btw.

Reviewed by:    ngie
Differential Revision:  https://reviews.freebsd.org/D56718

Add PCI device IDs for two Ice Lake PCH SMBus controller variants:
- 0x34a3 (Ice Lake-LP), previously listed as the generic "Ice Lake" entry (ID_ICELAKE), renamed to ID_ICELAKELP for clarity.
- 0x38a3 (Ice Lake-N), a separate PCH variant not previously supported.

Reviewed by:    adrian
Differential Revision:  https://reviews.freebsd.org/D56732

Reorder the TLS RX teardown sequence so the TIR is destroyed before
the DEK.  DESTROY_TIR for a TLS-enabled TIR issues a TRA RX fence
that drains all in-flight packets from the crypto pipeline.  If the
DEK is destroyed first, packets still in flight hit a TPT encryption
error (vendor syndrome 0x55) because the key they reference is
already gone.

Reviewed by:    kib
Sponsored by:   Nvidia networking
MFC after:      1 week

The virtio_p9fs module event handler can be invoked multiple times.
Previously, this caused p9_init_zones() and p9_register_trans() to be
executed multiple times, leaking UMA zones and corrupting the transport
list. During module unload, p9_destroy_zones() was also called multiple
times on the same zone pointers, triggering a duplicate free kernel panic
in uma_zdestroy().

This patch introduces a static reference counter in vt9p_modevent() to
ensure the zones and transports are only initialized and destroyed exactly
once, aligning with the approach used by other virtio drivers like vtnet.

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

The smartpqi driver did not log device add/remove or controller events
to syslog, and hw.smartpqi.debug_level could only be set at boot via
loader.conf with no runtime sysctl interface.

Add a read-write sysctl at dev.smartpqi.N.debug_level for runtime
debug level changes. Add device_printf calls for device addition,
removal, and controller events (hotplug, hardware, physical/logical
device, AIO state/config changes) so state changes always appear in
dmesg. Add DBG_DISC logging for discovery state transitions. Fix
spelling errors in strings and comments across the driver.

Bump driver version to 14.4691.1.2000 / 15.2.1.2000.

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294161
Reviewed by:    imp
Approved by:    imp
MFC after:      2 weeks

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

MFC after:    1 week
Sponsored by:   Chelsio Communications

Assign the driver type instead of preserving uninitialized stack data

PR:     https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294899
Reviewed by:    aokblast

eecp holds the extended capability offset. If that offset is larger
than 0xff, storing it in uint8_t truncates it, which can make the
early EHCI/XHCI capability walk read the wrong location and loop during
boot.

Seen on AMD device 1022:151e, where HCCPARAMS1 = 0x0118ffc5 and the
first xHCI extended capability offset is 0x460. Widen eecp to uint32_t
in xhci_early_takeover(), matching xhci_pci_take_controller().

Signed-off-by: Gisle Nes <gisle@gisle.net>
Reviewed by:    zlei, aokblast
MFC after:      3 days
Pull Request:   https://github.com/freebsd/freebsd-src/pull/2127
Closes:         https://github.com/freebsd/freebsd-src/pull/2127

SCTP states should always have a src scrub object associated with them.
Crafted pfsync packets might not have this, leading to us derferencing a
NULL pointer on cleanup.

Validate the pfsync state insertion packet to make sure this is correct.

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294989
MFC after:      1 week
Sponsored by:   Rubicon Communications, LLC ("Netgate")

We insert rules in pf_krule_global solely for the benefit of the
'keepcounters' feature. Failing to insert (beause the rule hash
collides, or an identical rule already exists) would be worse than
restoring counts to the wrong rule (or failing to restore them at all).

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282863, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294860, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294859, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294858
MFC after:      3 days
Sponsored by:   Rubicon Communications, LLC ("Netgate")
Differential Revision:  https://reviews.freebsd.org/D56745

Running sys/net tests in parallel reveals some panics which look like
the one below:

```
shared lock of (sx) vlan_sx @ /home/markj/sb/main/src/sys/net/if_vlan.c:2395
while exclusively locked from /home/markj/sb/main/src/sys/net/if_vlan.c:1850
panic: excl->share
cpuid = 9
time = 1776467219
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00d84e0780
vpanic() at vpanic+0x136/frame 0xfffffe00d84e08b0
panic() at panic+0x43/frame 0xfffffe00d84e0910
witness_checkorder() at witness_checkorder+0xdb1/frame 0xfffffe00d84e0ad0
_sx_slock_int() at _sx_slock_int+0x64/frame 0xfffffe00d84e0b10
vlan_ioctl() at vlan_ioctl+0x25c/frame 0xfffffe00d84e0b70
if_setflag() at if_setflag+0xdc/frame 0xfffffe00d84e0be0
ifpromisc() at ifpromisc+0x27/frame 0xfffffe00d84e0c00
vlan_setflags() at vlan_setflags+0x64/frame 0xfffffe00d84e0c30
vlan_unconfig_locked() at vlan_unconfig_locked+0xb7/frame 0xfffffe00d84e0c70
vlan_clone_destroy() at vlan_clone_destroy+0x5d/frame 0xfffffe00d84e0cb0
if_clone_destroyif_flags() at if_clone_destroyif_flags+0x8c/frame 0xfffffe00d84e0cf0
if_clone_detach() at if_clone_detach+0x106/frame 0xfffffe00d84e0d20
vnet_destroy() at vnet_destroy+0x154/frame 0xfffffe00d84e0d50
prison_deref() at prison_deref+0xaf5/frame 0xfffffe00d84e0dc0
sys_jail_remove() at sys_jail_remove+0x1a7/frame 0xfffffe00d84e0e00
amd64_syscall() at amd64_syscall+0x169/frame 0xfffffe00d84e0f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00d84e0f30
--- syscall (508, FreeBSD ELF64, jail_remove), rip = 0x25bd44705ca, rsp = 0x25bcfe72ab8, rbp = 0x25bcfe72b40 ---
```

All vlan interfaces are locked by a single recursive global lock.  There
are cases, like in the panic above where vlans are stacked on top of
each other, where the driver tries to acquire an exclusive lock while
holding a shared lock, and vice versa.

With longer-term goals of making the networking regression test suites
stable when run in parallel, and simplifying network control plane
locking, which I find is quite complex and buggy, let's change if_vlan
to use the exclusive lock everywhere.

Reviewed by:    pouria, zlei, kp, glebius
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D56778

Set the ifp variable as soon as soft_c becomes available
so that interface statistics can be incremented.

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295129
Reported by:    Robert Morris <rtm@lcs.mit.edu>
Fixes:          https://cgit.freebsd.org/src/commit/?id=e44d2e941e8e ("if_geneve: Add Support for Geneve ...")

The FreeBSD-base bits are accessible via pkg.FreeBSD.org, even for
releases, so there is no need to point at pkgbase.FreeBSD.org.

MFC after:      3 days

This is useful for testing alternative service managers
without modifying /etc/rc

MFC After:      1 weeks
Reviewed by:    kib
Differential Revision:  https://reviews.freebsd.org/D56828

Ever since certctl was rewritten in C, the rehash command has reingested
TRUSTDESTDIR / UNTRUSTDESTDIR in addition to TRUSTPATH / UNTRUSTPATH.
This seemed like a good idea at the time but was, in retrospect, a
mistake, as it means a (un)trusted certificate remains (un)trusted
forever (or at least until it expires) even if it is removed from
(UN)TRUSTPATH.  Among other issues, it causes ports QA to fail for any
port that either installs certificates or depends on a port that does.

Although this behavior was undocumented, the change may surprise users
who have added certificates manually, so update the manual page to point
it out and add prominent warnings to the trust and untrust commands.

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290078
MFC after:      1 week
Reviewed by:    kevans, bcr
Differential Revision:  https://reviews.freebsd.org/D56617

Previously, devmatch would stop at the first linker.hints file
found in kern.module_path. This meant modules installed in
/boot/modules/ were invisible to devmatch if /boot/kernel/
contained a linker.hints file (which it always does).

Merge hints from all directories in kern.module_path.
This allows third-party or out-of-tree kernel modules in
/boot/modules/ to be auto-loaded by devmatch just like
built-in modules.

Reviewed by:            imp
Differential Revivion:  https://reviews.freebsd.org/D56847

If anyone would build bhyve with -DNDEBUG, any code in the expression
in assert() won't be executed.  Instead put the return value in a
temporary variable to assert that it has the expected value.

Reviewed by: emaste, markj (earlier version)
Fixes: https://cgit.freebsd.org/src/commit/?id=2a514d377b37 ("bhyve/virtio-scsi: Preallocate all I/O requests")
Differential Revision: https://reviews.freebsd.org/D55803

Currently rtadvd ignores interface pltime/vltime specifications
unless the (static) address range is also included in the config file.
This extends the validity of a pltime and/or vltime stanza in
the config file for an interface to delegated addresses from
an upstream provider.

Signed-off-by:  tickerguy <karl@denninger.net>
PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288426
Reviewed by:    pouria
Pull Request:   https://github.com/freebsd/freebsd-src/pull/1863

This fixes a regression introduced in cae280931c9e which prevents
user_data as a shell script to be used

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295062
Reported by:    Ross McKelvie <ross@exitzero.uk>
MFC After:      1 day

Ensure the script used is invalid when parsed by libyaml which
highlight the issue revealed in PR295062

while at here validate the mode of the file is properly changed

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295062
MFC After:      1 day

The jail(8) command must not leave parsed configuration files open
since the file descriptors will be leaked to child processes
including the untrusted exec.start or exec.stop hooks.

While fopen() doesn't provide direct access to O_CLOEXEC, it does
provide access to FD_CLOEXEC via "e" in the mode string which
provides the desired defense in depth against leaking file descriptors
into exec.* hooks since those always execve() into a shell.

Jail configuration is potentially sensitive and some hooks execute from
within the jail context, leaving some opening for the jail to exfiltrate
information about the host environment.

(Commit message wordsmithed by kevans)

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295052
Reviewed by:    kevans
MFC after:      3 days

This protects against accidentally leaking them past fork()+exec()
in future refactorings.

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295052
Reviewed by:    kevans

Avoid dependency on INET (IPv4) by using PF_LOCAL,
allowing media check to work on systems without INET support.

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295045
Reviewed by:    kevans
MFC after:      1 week

The FreeBSD network stack, for better or worse, does not impose any
requirements on interface names. As such it's valid for an interface
name to start with a number (or indeed, be something like '⭐').

Allow this in pfctl, and add a test case for the specific case of
interface names starting with a number.

Note that we don't support UTF-8 names fully, so those may still fail.

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295064
MFC after:      1 week
Sponsored by:   Rubicon Communications, LLC ("Netgate")

When fsck_msdosfs runs with FAT32 cache mode (used for large
filesystems that cannot be mmap'd), a detected FAT header correction
was written into the in-memory buffer but the corresponding cache
entry (fat32_cache_allentries[0]) was never marked dirty.  As a
result, fat_flush_fat32_cache_entry() skipped it, the corrected
bytes were never written to disk, and copyfat() propagated the
uncorrected on-disk data to all backup FAT copies.  Every subsequent
fsck run would repeat the same "FAT starts with odd byte sequence /
FIXED" cycle indefinitely.

Fix by marking fat32_cache_allentries[0].dirty = true after applying
the in-memory correction, ensuring the chunk is flushed before
copyfat() runs.

Obtained from:  https://android-review.googlesource.com/c/platform/external/fsck_msdos/+/4047981
MFC after:      3 days

This is only used by rc.subr and belongs in rc, not runtime.

Fixes:          https://cgit.freebsd.org/src/commit/?id=fa6d67cd16b5 ("BSD.root.dist: Add package tag for all directories")
MFC after:      3 days
Reviewed by:    ivy
Differential Revision:  https://reviews.freebsd.org/D56900

Reviewed by:  imp, kib
Differential Revision:  https://reviews.freebsd.org/D56908

nuageinit: add decode_base64 tests

nuageinit: add addsudo tests

nuageinit: add adddoas tests

nuageinit: add update_sshd_config tests

MFC after:      2 weeks
Sponsored by:   The FreeBSD Foundation

Reviewed by:    lwhsu, markj
MFC after:      2 weeks
Sponsored by:   The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D51736

The return value of posix_spawn_file_actions_init() is an error number.

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

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

From the PR:
The attached diff implements the inverse square root function, i.e,
rsqrt(x) = 1 / sqrt(x).  Exhaustive testing of the float version
suggests that it is correctly rounded in round-to-nearest for all
test values in the range [0x1p-127,0x1p126].
Exhaustive testing of rsqrt and rsqrtl cannot be done, but 1100M
values of x for rsqrt and 400M values for rsqrtl were tested.  All
tested values were correctly rounded.

I do not have access to LD128 (i.e., IEEE 128-bit floating point)
hardware, so the implementation of rsqrtl() is untested.

The following is a summary of changes to source code.

* lib/msun/Makefile:
  . Add s_rsqrt.c and s_rsqrtf.c to COMMON_SRCS.
  . For non-53-bit long double targets, add s_rsqrtl.c to COMMON_SRCS.
  . Add MLINKS for rsqrt.3, rsqrtf.3, and rsqrtl.3 to sqrt.3.

* lib/msun/Symbol.map:
  . Add rsqrt, rsqrtf, and rsqrtl to the Symbol map for shared libm.so.

* lib/msun/man/sqrt.3:
  . Update the sqrt.3 manual page to include information for rsqrt[fl].
  . Note, these function come from ISO C23 (and IEEE-754 2008).

* lib/msun/src/math.h:
  . Add prototypes for new functions.

* lib/msun/src/math_private.h:
  . Add _SPLIT, _FAST2SUM, _SLOW2SUM, _XADD, _MUL, and _XMUL
    macros to perform type-type arthimetic (i.e., float-float).

* src/s_rsqrt.c:
  . New file with the implementation of 'double rsqrt(double)'.
  . For 53-bit long double targets, add a weak reference for rsqrtl.

* src/s_rsqrtf.c:
  . New file with the implementation of 'float rsqrt(float)'.

* src/s_rsqrtl.c
  . New file with the implementation of 'long double rsqrt(long double)'.
    Note, the LD80 version uses bit twiddling and LD128 version is a
    straight C language implementation.  The LD128 is untested due to
    lack of hardware.

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

The client tells the server how many callback slots
it can handle in the callback session.  However, the
NFSv4.1/4.2 server can only handle a maximum of
NFSV4_SLOTS slots.  This patch clips the client's
value to that, to avoid using too high a slot#
for a callback.

Fortunately, I do not know of an extant client that
specifies a value greater than NFSV4_SLOTS, so this
patch is not really needed, as yet.  Also, the client
rarely uses a slot# above 0 when doing callbacks.

MFC after:      2 weeks

In ncl_getcookie(), a very large value for "off" for
a directory can result in "pos" being set to a bogus
value (including a negative one), due to truncation.
When "pos" is negative, is can skip past the
while (pos >= NFSNUMCOOKIES) loop and return a
bogus pointer instead of NULL.

This patch changes the type to u_int and also adds
a sanity check for a very large "off" to ensure that
a NULL pointer is returned for this case.

This bug has been in the code for decades and I am
not aware of any report of it causing a problem for
users.

Reviewed by:    markj
Reported by:    Joshua Rogers of AISLE Research Team
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D56779

This is needed for various pjdfstest tests which fail with syntax errors
if pathconf _PC_NAME_MAX/_PC_PATH_MAX return -1. For NAME_MAX we can use
the 9P2000.L Tstatfs call to get namelen from the host. While this could
theoretically be different for nested filesystems in the shared mount it
is a much better guess than just returning 255.
There does not seem to be a way to get the host PATH_MAX, so we just
return the conservative kernel default.

Found while fixing https://github.com/CTSRD-CHERI/cheribsd/issues/2617.

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

When a file is created via p9fs with restrictive permissions (like 000),
the 9P TCREATE request successfully creates and natively opens the file,
returning an open, writable file descriptor. Previously, p9fs would
attempt a subsequent TOPEN. That TOPEN would fail with EACCES due to the
restrictive mode, leaving a 0-byte file and causing operations like 'mv'
to abort.

We now preserve the writable descriptor returned by TCREATE so that the
subsequent VOP_OPEN can use it directly, avoiding the failing TOPEN.
Additionally, p9fs_compatible_mode now appropriately isolates the base
access intent when matching fids, preventing extended flags from
breaking the match.

A test case for this behavior has been submitted to pjdfstest:
https://github.com/pjd/pjdfstest/pull/87

Resolves: https://github.com/CTSRD-CHERI/cheribsd/issues/2617

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

This helps ensure that overflows will trigger a panic instead of
silently corrupting adjacent buffers, as happened in SA-26:13.exec.

Extend kmap_alloc_wait() to support allocation of guard pages on both
sides of a KVA allocation.  Modify the exec_map setup accordingly.  Add
the "vm.exec_map_guard_pages" tunable to provide control over the guard
page allocations.

Reviewed by:    kib
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D56711

This fixes an "unused variable" warning when building DRM drivers.

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

nfs_pub is used only in vfs_export.c.

Reviewed by:    kib, rmacklem
Differential Revision:  https://reviews.freebsd.org/D56777

Writing to /proc/$pid/regs can also be leveraged to mess with memory.

Only allow a trusted process to do so.

Sponsored by: Hewlett Packard Enterprise Development LP.

Reviewed by:    olce
Differential Revision:  https://reviews.freebsd.org/D56763

eventhandler: Fix a race when pruning eventhandlers

By default, eventhandler_deregister() blocks until it reaches some point
where no threads are invoking the event.  At this point, it knows that
1) no threads are currently executing the handler,
2) some thread has freed the eventhandler structure by virtue of having
   called eventhandler_prune_list(),
so it is safe to return.

Suppose a thread is trying to deregister an event handler.  A different
thread prunes it, and wakes up the first thread.  Before the first
thread runs, a third thread grabs the event handler lock, and starts
executing handlers.  The first thread observes el_runcount > 0, and goes
back to sleep.  The third thread sees no event handlers to prune, and
doesn't wake up the first thread, which sleeps forever.

This change fixes the race and tries to make eventhandler_invoke() more
efficient: keep a count of the number of dead list entries and only
prune the list if there is at least one dead entry.  Also, in
eventhandler_deregister(), we only need to sleep if some dead entries
are present, rather than sleeping whenever some thread is running
handlers.

Reviewed by:    kib
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D56767

eventhandler: Fix the NODEBUG build

Reported by:    Michael Butler <imb@protected-networks.net>
Fixes:          https://cgit.freebsd.org/src/commit/?id=735b16d490ae ("eventhandler: Fix a race when pruning eventhandlers")

The __maybe_unused attribute should be used for variables which may or
may not be used, such as when their only use is in an assertion. This
attribute is functionally identical to __unused, suppressing compiler
warnings for particular variable if it remains unused.

Reviewed by:    Minsoo Choo <minsoo@minsoo.io>, imp
Differential Revision:  https://reviews.freebsd.org/D56517

Inspired by discussion in
https://github.com/freebsd/freebsd-src/pull/2016

Reviewed by:    imp
Differential Revision:  https://reviews.freebsd.org/D56624

Blocking allocation is safe in all of the current callers of kobj_init
(most of them do a M_WAITOK malloc of the structure passed as the
first argument to kobj_init just before calling it).  kobj_init
doesn't return an error code but instead panics if the nested malloc
in kobj_class_compile1 fails, so using M_WAITOK here is more robust.

Reviewed by:    imp
Differential Revision:  https://reviews.freebsd.org/D56625

Just put the priv_check calls in the code.

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

This ensures this header can be included without an explicit or implicit
sys/types.h include first. This causes issues building SPEC2017 which
includes sys/rtprio.h and then we get an error due to missing u_char
definition.

Reviewed by:    emaste
MFC after:      1 week
Differential Revision: https://reviews.freebsd.org/D52041

Previously, the UMA zones required for 9P requests (p9fs_buf_zone,
p9fs_req_zone, etc.) were initialized and destroyed in the
virtio_p9fs transport module. This caused issues when unloading
the core p9fs module.

This change moves p9_init_zones() and p9_destroy_zones() into
p9fs_init() and p9fs_uninit() inside p9fs_vfsops.c so that they
are correctly bound to the VFS filesystem module lifecycle via
vfs_modevent, aligning p9fs with standard FreeBSD VFS semantics.

Found while fixing https://github.com/CTSRD-CHERI/cheribsd/issues/2617.

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

Only call buf_flush() if there are some dirty buffers belonging to the
vnode we are allocating the buffer for.  Otherwise the bd dirty queue
scan cannot find anything and it makes no sense to spend CPU doing it.

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week

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

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

Noted by:     alc
Sponsored by:   The FreeBSD Foundation
MFC after:      1 week

Previously the cr_pid field would be incorrectly copied to userland, due
to a size mismatch between the structure as defined in 32-bit vs 64-bit
builds.  Fix it by converting the structure before copying it to
userland.

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294833
Sponsored by:   ConnectWise
MFC after:      1 week
Reviewed by:    emaste
Differential Revision: https://reviews.freebsd.org/D56675

Suggested by: kib
Reviewed by:    imp, kib
Discussed with: emaste, jrtc27
Differential Revision:  https://reviews.freebsd.org/D56783

Suggested by: kib
Reviewed by:    imp, kib
Differential Revision:  https://reviews.freebsd.org/D56401

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

for MacOSX partial compatibility, defined as O_PATH | O_NOFOLLOW.
fstat(2) and freadlink(3) works on the resulting file descriptors,
but reads on the regular file do not.

More complete but more hackish version was developed but deemed too
hackish.

Sponsored by:   The FreeBSD Foundation
MFC after:      2 weeks
Differential revision:  https://reviews.freebsd.org/D56365

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

to indicate non-empty vnode knote list.  Use it instead of
VN_KNLIST_EMPTY() and guard note activations with it.

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

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

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

The source sweep is not going to happen.

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

Commit c4f08d46c7f7 moved the symlinks for the LLVM binutils from LLVM
itself to the toolchain (usr.bin/clang/toolchain), but did not remove
the links for /usr/bin/gcov and /usr/bin/objdump from the llvm version,
meaning we installed them twice, once in the clang package and once in
the toolchain package.

Remove the links from the llvm version and move the MLINKs to toolchain,
which is where the other MLINKs dwell.

While here, fix toolchain to use the correct build option for llvm-cov,
MK_LLVM_COV.

Fixes: https://cgit.freebsd.org/src/commit/?id=c4f08d46c7f7 ("llvm-*: Move all LLVM_BINUTILS symlinks to toolchain package")
Reported by:    jrm
Reviewed by:    jrm, dim, emaste
Sponsored by:   https://www.patreon.com/bsdivy
Differential Revision:  https://reviews.freebsd.org/D56788

Commit d1c176fedfc9 made create-sets.sh exit when it encounters an
error, instead of creating an empty repository.  However, this turns
out to cause some issues:

1. A package not having any sets is considered an error, but during
   the release build, we stuff a 'pkg' package into the repository
   which doesn't have any sets, which causes a failure.  Avoid this
   by simply ignoring the pkg package.

2. No error was printed in this case, which made the problem hard
   to diagnose.  Add an explicit error message.

3. A similar problem occurred running on a repository which already
   contained sets, which is not usually done during the build, but
   is not necessarly an inappropriate thing to do.  Fix this one by
   ignoring set packages when looking for sets.

While here, fix another issue that might cause packages to be wrongly
skipped if the path to the repository contains a '-' character, since
we didn't strip the path before testing the package name.

PR:     https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294966
Fixes:  https://cgit.freebsd.org/src/commit/?id=d1c176fedfc9 ("packages: Make create-sets.sh more robust")
MFC after:      2 weeks
Reported by:    Alastair Hogge <agh@riseup.net>
Reviewed by:    emaste
Sponsored by:   https://www.patreon.com/bsdivy
Differential Revision:  https://reviews.freebsd.org/D56792

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

Make it clear which of two possible cases applies.

Reviewed by: cperciva
Differential Revision: https://reviews.freebsd.org/D56837

MFC after:    1 week
Differential Revision:  https://reviews.freebsd.org/D56831

Reviewed by:  kp
MFC after:      1 week
Obtained from:  60d8dbbef075 netinet: add a probe point for IP, IP6, ICMP, ICMP6, UDP and TCP stats counters
Differential Revision:  https://reviews.freebsd.org/D53709

Enabling ZSTD_TRACE leaves behind undefined weak symbols, which causes a
problem for gcc builds.  The bfd linker emits an obscure error about
overlapping FDEs.  We don't need ZSTD_TRACE for libsa, so just disable
it.

Also disable BMI2 instruction optimizations.  The addition of the
optional BMI2 code paths caused the boot loader binaries to grow larger
(28 KiB for clang, 32 KiB for gcc).  The boot loader binaries are size
constrained, and this pushed the gcc-generated lua_loader.bin over the
500000 byte limit, and the clang one to within 4k of the limit.

Fixes:  https://cgit.freebsd.org/src/commit/?id=8a62a2a5659d ("zfs: merge openzfs/zfs@https://cgit.freebsd.org/src/commit/?id=f8e5af53e")
Reviewed by:    delphij, imp, mm
Differential Revision:  https://reviews.freebsd.org/D56866

Reviewed by:  kib
Discussed with: markj, royger
MFC after:      3 days
Differential Revision:  https://reviews.freebsd.org/D54070

If the user runs "make update-packages" without bumping BRANCH, then it
isn't possible to copy packages from the old location to the new one
(because the two locations are the same).  So just skip that step.

Sponsored by:           ConnectWise
PR:                     https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295085
MFC after:              1 week
Reviewed by:            ivy, emaste
Differential Revision:  https://reviews.freebsd.org/D56872

Fixes:        https://cgit.freebsd.org/src/commit/?id=bb75b0d581f7 ("packages: Convert world to a subdir build")
MFC after:      2 weeks
Reviewed by:    des, emaste
Differential Revision:  https://reviews.freebsd.org/D56839

Fixes:        https://cgit.freebsd.org/src/commit/?id=448ec129bcef ("git-arc: Add a create-draft mode")

Gcc complained about the unused %0 asm argument.

Fixes:  https://cgit.freebsd.org/src/commit/?id=2c2ec6bbc9cc ("tests/sys/arch/amd64: add a program to check INT $0x80 behavior on amd64")
Reviewed by:    kib, markj
Differential Revision:  https://reviews.freebsd.org/D56781

MFC after:    2 weeks

The test assumes UTC, which is what I use on my development systems and
clearly what is used on our CI runners.

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

Don't waste time generating Perl test cases for algorithms that are not
supported in Perl mode only to skip them when they are run.

MFC after:      1 week
Reviewed by:    ngie
Differential Revision:  https://reviews.freebsd.org/D56687

Test what happens when we ask for the rdev of a non-device.

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

Reported by:  adrian
Sponsored by:   The FreeBSD Foundation

Notable upstream pull request merges:
 #18473 b8d959640 Fix rare cksum errors after rebuild
 #18477 e78a51dd6 Fix off-by-one in PREVIOUSLY_REDACTED handler that drops
                  last block
 #18482 d5099c330 Initialize vr_last_txg for rebuild
 #18483 872f01019 Zstd: rework ZSTD_isError symbol renaming
 #18489 366b1f9a3 Fix long POSIX_FADV_DONTNEED for single block files

Obtained from:  OpenZFS
OpenZFS commit: a12c6ed62fcd06093b95616515e4716b0b0bc038

  Thread Safety Analysis: Fix pointer handling of variables with deprecated attributes (#148974)

  de10e44b6fe7 ("Thread Safety Analysis: Support warning on
  passing/returning pointers to guarded variables") added checks for
  passing pointer to guarded variables. While new features do not
  necessarily need to support the deprecated attributes (`guarded_var`,
  and `pt_guarded_var`), we need to ensure that such features do not cause
  the compiler to crash.

  As such, code such as this:

          struct {
            int v __attribute__((guarded_var));
          } p;

          int *g() {
            return &p.v;  // handleNoMutexHeld() with POK_ReturnPointer
          }

  Would crash in debug builds with the assertion in handleNoMutexHeld()
  triggering. The assertion is meant to capture the fact that this helper
  should only be used for warnings on variables (which the deprecated
  attributes only applied to).

  To fix, the function handleNoMutexHeld() should handle all POK cases
  that apply to variables explicitly, and produce a best-effort warning.

  We refrain from introducing new warnings to avoid unnecessary code bloat
  for deprecated features.

  Fixes: https://github.com/llvm/llvm-project/issues/140330

This fixes an assertion while building the net/openvswitch port:
"Assertion failed: ((POK == POK_VarAccess || POK == POK_VarDereference)
&& "Only works for variables"), function handleNoMutexHeld, file
/usr/src/contrib/llvm-project/clang/lib/Sema/AnalysisBasedWarnings.cpp,
line 2120.'

Reported by:    cy
PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295101, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292067
MFC after:      1 month

Reviewed by:  glebius
Sponsored by:   Netflix
Differential Revision:  <https://reviews.freebsd.org/D55998>

This reverts commit b5bad6df467cc95bea641afe674c55cd5b9f1510.

Revert until we can fix reported issues

This reverts commit c16c95192f01237a876eb7bc336e3bbda9310171.

Revert until we can fix reported issues

libusb: change callback register handler to int

libusb upstream uses int for register handler. This causes some library
user (like pyusb) to assume that we have int in all implementations and
therefore provides a 4 byte storage only. This causes Segmentation
fault as we will right the pointer.

Reviewed by:    adrian
Sponsored by:   The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D54211

Revert "libusb: change callback register handler to int"

This reverts commit ce9ced951a0b9d004a3b007d4ac6e9087a1301a2.

We should handle backward compatibility before introducing this patch as
people may rely on old ABI.

This reverts commit de2ea5423cc63b62e7e42d11b667aa634109fc28 which is
no longer needed after 1dddb580f950 .

Tested by:      mmel

Per [siva@'s comment on the PR][1], this testcase now passes cleanly in CI.

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

[1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274941#c6

This reverts commit 86e87c3bd1b377242aafe7e2222ae17ca0be96d9.