FreeBSD git weekly: 2025-11-10 to 2025-11-16

OpenPAM is a discrete, largely self-contained system component.
Users may not need PAM for many use-cases (e.g. jails, containers),
so move it to its own package.

Use LIB_PACKAGE to create a separate pam-lib package for libpam,
so that applications that support PAM don't need to bring in all
the PAM modules if PAM isn't actually in use.

Add pam to the minimal sets, since this is a core system component that
people expect to be installed.  This means all supported installation
methods will install the PAM modules by default, so don't add explicit
dependencies on the PAM modules from things that use PAM (e.g. runtime),
allowing custom/embedded systems to omit these easily.

This change adds a new package to the system so, until we have a proper
policy on how to handle this in release/stable branches, it should not
be MFC'd.

MFC after:      never
Reviewed by:    des, bapt
Sponsored by:   https://www.patreon.com/bsdivy
Differential Revision:  https://reviews.freebsd.org/D53602

This new function computes the alignment of a pointer.
It is part of ISO/IEC 9899:2024, the new C standard.
If the pointer is a null pointer, null is returned.
I have tried to write an implementation that can cope
with traditional address-based architectures, even if
size_t and uintptr_t are of different length.  Adjustments
may be needed for CHERI though.

A man page is provided, too.  No unit test for now.

Reviewed by:    kib, imp, ziaee (manpages), pauamma@gundo.com
Approved by:    markj (mentor)
MFC after:      1 month
Relnotes:       yes
Differential Revision:  https://reviews.freebsd.org/D53673

Reminded by:  yasu

Add support for a field width, which defaults to 9 if unspecified or
zero.  If the width is not exactly 9, we have to either cut off digits
or append zeroes to make up the difference.  If the width is a dash,
we pick a width based on the clock's reported resolution.  This brings
us in line with GNU coreutils.

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287080
MFC after:      1 week
Reviewed by:    0mp
Differential Revision:  https://reviews.freebsd.org/D53667

In the manual page:
- Fix synopsis and use better argument names
- Improve description of flags.
- In EXAMPLES, list the contents of iguana and chameleon files.
- Use Rs to reference The Cartoon Guide to Statistics
- Fix misc indentation and style issues
- Tag SPDX

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

Historically, lam(1) closes stdin once we've hit EOF the first time,
which would stop it from doing anything else on subsequent gatherline()
calls with another openfile.  However, this doesn't seem to be strictly
necessary- the EOF flag on FILEs is quite sticky, so we can assume that
a subsequent fgetc(stdin) will flag EOF properly.

This 'fixes' the below-referenced commit in the sense that it surfaced
this problem as a fatal error, but the issue was pre-existing.  If we
do `lam - -`, then one gatherline() will fclose(stdin) and set `ip->eof`
for *that* openfile, while the next one will then observe that
STDIN_FILENO has been closed and turn it into an EBADF.

Add a few tests that were easy to snipe while I'm here, but I haven't
aimed for anything close to exhaustive because I think re@ would prefer
this fix go in sooner rather than later to land in 15.0.

Minor style adjustment for the previous commit while we're here.

Reported by:    cperciva
Discussed with: jrtc27
Reviewed by:    des, jlduran
Fixes:  https://cgit.freebsd.org/src/commit/?id=4472fd66d006 ("lam: fail on I/O errors")
MFC after:      3 days (tentative)
Sponsored by:   Klara, Inc.
Differential Revision:  https://reviews.freebsd.org/D53750

MFC after:            3 days
Reviewed by:            pauamma_gundo.com
Differential Revision:  https://reviews.freebsd.org/D53748

MFC after:            3 days
Reviewed by:            ziaee
Fixes:                  https://cgit.freebsd.org/src/commit/?id=dea5f973d0c8 (new Intel Ethernet E610 family)
Differential Revision:  https://reviews.freebsd.org/D52990

This updates the nuageinit man page by aligning mentions of the
cloud-config header line with the cloud-init documentation[0], removing
an unwanted "!" character.

[0] https://docs.cloud-init.io/en/latest/explanation/about-cloud-config.html#how-do-i-create-a-cloud-config-file

Signed-off-by: Jonathan Matthews <freebsd@hello.jonathanmatthews.com>
Differential Revision:  https://reviews.freebsd.org/D53706

Explain how to collect E610 device debug dump data with sysctl for
troubleshooting with Intel Customer Support.

Fixes:                  https://cgit.freebsd.org/src/commit/?id=2170400142b9 (Add support for debug dump)
Reviewed by:            bcr, erj (previous version), ziaee
Signed-off-by:          Yogesh Bhosale <yogesh.bhosale@intel.com>
Differential Revision:  https://reviews.freebsd.org/D52990

+ tag SPDX
+ add sysctl to apropos database
+ fix markup of examples and reflow a overly long line
+ add a hardware section for hw relnotes

MFC after:      3 days

MFC after:    3 days

MFC after:    3 days
Fixes:          https://cgit.freebsd.org/src/commit/?id=76735c74398923a (flash: Add "n25q64" to mx25l driver)

Explain driver loading and application access in the body of the manual.
Crossreference other game controller driver manuals, and devfs.rules to
hint about how to configure application access. Add a common dongle to
supported hardware. Add evdev a few places to make it really clear how
it works.

MFC after:              immediately for inclusion in 15.0R
Reviewed by:            wulf
Differential Revision:  https://reviews.freebsd.org/D53290

MFC after:            immediately for inclusion in 15.0R
Reported by:            ivy
Differential Revision:  https://reviews.freebsd.org/D53745

* Rewrite the first paragraph to clarify that quot(8) only supports FFS.

* Document which options can or cannot be combined with each other.

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

console=comconsole is for the loader and boot_serial is for the kernel.

I think we should centralize documentation on the loader settings in one
manual, such a loader.8. The current proliferation is not obvious where
to find the documentation. To the user, these are all set in loader.conf
or at the loader prompt.

MFC after:              3 days
Differential Revision:  https://reviews.freebsd.org/D53695

Begin documenting module loader commands in loader(8), where the reader
would look for them. Segregate them by their availability in individual
loader implementations, like build(7) targets.
These details were graciously donated by kevans.

MFC after:              3 days
Reviewed by:            kevans
Co-authored-by:         Kyle Evans <kevans@freebsd.org>
Differential Revision:  https://reviews.freebsd.org/D50727

iwx.4: Fix SYNOPSIS

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290812
MFC after:      3 days
Fixes:          https://cgit.freebsd.org/src/commit/?id=27c41b28b1d7 (iwx.4: Initial manual page)
Reported by:    Dimitry Lukhtionov <dimitryluhtionov@gmail.com>

iwx.4: Follow the established style

Fixes:          https://cgit.freebsd.org/src/commit/?id=b0c1ead2b9be ("iwx.4: Fix SYNOPSIS")
Reviewed by:    ziaee
Differential Revision:  https://reviews.freebsd.org/D53760

Reviewed by;  ziaee
Sponsored by:   The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D52460

Reminded by:  yasu
MFC after:      3 days

Reminded by:  yasu

Sponsored by: The FreeBSD Foundation

Floppies have been obsolete for over a decade.  Add a deprecation note
now and plan to remove fdc(4) support in 16.

Reviewed by:    ziaee
Sponsored by:   The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41549

According to section 5.1.6.2.1 of version 1.3 of the virtio
specification, the driver MUST NOT set VIRTIO_NET_HDR_F_DATA_VALID in
the flags. So don't do that.

Reviewed by:            Timo Völker
MFC after:              3 days
Differential Revision:  https://reviews.freebsd.org/D53650

Transmit segment offloading depends on transmit checksum offloading.
Enforce that constraint. This also fixes a bug, since if_hwassist bits
are from the CSUM_ space, not from the IFCAP_ space.

PR:                     https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290773
Reviewed by:            Timo Völker
Tested by:              lg@efficientip.com
MFC after:              3 days
Differential Revision:  https://reviews.freebsd.org/D53629

nvmf: Add a transport hook to limit the size of host data transfers

Smart NIC offload transports may have a cap on the size of the largest
data PDU that can be received.  Allow these transports to enforce a
cap on the size of an I/O request submitted by the nvmf(4) host.

NB: The controller is able to advertise a maximum-supported PDU size
during TCP negotiation, but there is no way in the protocol to
advertise a maximum size that the host can receive.

Sponsored by:   Chelsio Communications

nvmf: Honor any data transfer limit imposed by the transport

If the transport has a data transfer limit, restrict I/O transfers to
the largest multiple of MPS that fits within the limit.

Sponsored by:   Chelsio Communications

nvmf: Add a transport hook to limit the maximum command capsule size

NVMe controllers advertise the largest supported size of a command
capsule in the controller data (IOCCSZ).  Smart NIC offload transports
may have a cap on the size of the largest data PDU that can be
received.  These transports can implement this hook to limit the
advertised IOCCSZ to limit the in-capsule-data payload sent by remote
hosts.

Sponsored by:   Chelsio Communications

Sponsored by: Chelsio Communications

- Default to enabling all NVMe capabilities.  Currently, NVMe/TCP PDU
  offload is supported by T7 adapters.

- Fetch relevant parameters from the firmware if NVMe support is
  enabled.  A few parameters are shared with RDMA support, so the RDMA
  parameters section is now split into handling for parameters used by
  both vs parameters used only by RDMA.

Sponsored by:   Chelso Communications

NVMe/TCP offload depends on TOE similar to iSCSI and iWARP offloads.

Sponsored by:   Chelsio Communications

These work requests are largely similar to the same work requests for
iSCSI offload but use a newer tx_data work request structure.

This includes initial support for ISO where a large C2H_DATA or
H2C_DATA PDU is split into multiple PDUs on the wire.

Sponsored by:   Chelsio Communications

- Adds various per-queue counters similar to iSCSI PDU offload as well
  as a hook in the adapter softc for a reference to the NVMe/TCP softc.

- Instruct the firmware to include a DDP indicator in the status field
  for NVMe/TCP PDU completion messages.  This flag indicates if the
  payload data for a PDU has been received in the free list or if it
  was placed directly into a kernel I/O data buffer via DDP.

Sponsored by:   Chelsio Communications

Similar to iSCSI on T6+, additional DDP data might have been received
without a completion posted if a connection was closed in the middle
of a transfer.

Sponsored by:   Chelsio Communications

nvmf_che: NVMe-TCP offload support for Chelsio T7 adapters

This provides an alternative NVMe over TCP transport which uses PDU
offload for TOE connections on a T7.

Similar to iSCSI offload via cxgbei.ko, nvmf_che uses DDP when
possible to enable the NIC to DMA received data directly into I/O data
buffers (pages from a struct bio on the host side, pages from a CTL
I/O requests on the controller side) to avoid copying data on the host
CPU.  nvmf_che is also able to receive a stream of C2H or H2C PDUs for
a single data transfer when using DDP without processing the header of
each PDU.

Unlike cxgbei, nvmf_che aims to be mostly transparent to end users.
Notably, neither nvmecontrol or ctld have to be explicitly asked to
use an offload.  Instead, TCP queue pairs are claimed by this driver
whenever they are eligible (e.g., using TOE).

The main restriction of nvmf_che compared to the software TCP
transport is that Chelsio adapters have a restriction on the largest
PDU that can be sent and received.  When sending data, nvmf_che is
able to split large C2H or H2C data requests across multiple PDUs
without affecting nvmf(4) or nvmft(4).

To avoid overly large PDUs when using nvmf(4), nvmf_che reports a data
transfer limit that is honored by nvmf(4).  This ensures that the
remote controller's PDUs will never be too large (since the command
transfer size is limited to one PDU) and also ensures that nvmf(4)
will never to try to send a command PDU with ICD that is too large.

For nvmft(4), overly large command PDUs due to ICD are avoided by
clamping the size of the reported IOCCSZ in the controller data.
However, to ensure that H2C PDUs are sufficiently small, nvmf_che will
only claim queue pairs which advertised a suitable MAXH2CDATA
parameter during queue negotiation.  For ctld(8), this can be achieved
by setting the MAXH2CDATA option in a transport-group, e.g. for T7:

transport-group tg0 {
        discovery-auth-group no-authentication
        listen tcp 0.0.0.0
        listen tcp [::]
        listen discovery-tcp 0.0.0.0
        listen discovery-tcp [::]
        option MAXH2CDATA 32488
}

Sponsored by:   Chelsio Communications

nvmf_che: Fix amd64 LINT-NOVIMAGE build

Fixes:  https://cgit.freebsd.org/src/commit/?id=ec0cd287f55f nvmf_che: NVMe-TCP offload support for Chelsio T7 adapters
Sponsored by:   Chelsio Communications

cxgbe(4): fix nvmf_che module build

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

When vchans are enabled, the primary channels do not interact with
userland, but with the vchans.

With vchans enabled:

$ sndctl feederchain
dsp0.play.0.feederchain=[vchans -> [...] -> hardware]
dsp0.record.0.feederchain=[hardware -> [...] -> vchans]

With vchans disabled:

$ sndctl feederchain
dsp0.play.0.feederchain=[userland ->  [...] -> hardware]
dsp0.record.0.feederchain=[hardware -> [...] -> userland]

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

Co-authored by:       meka@tilda.center
Sponsored by:   The FreeBSD Foundation
MFC after:      2 weeks
Reviewed by:    markj
Differential Revision:  https://reviews.freebsd.org/D53029

sound: Retire unused snd_dbuf->dir

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

sound: Retire snd_dbuf->dev

Redundant, and if we at some point really need this, we can fetch it
from snd_dbuf->channel->dev.

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

sound: Re-arrange sndbuf_create() arguments

Since we always use the channel name as the "drv" argument, we can just
get rid of it and fetch it in sndbuf_create(). Also, put the "channel"
argument first, as it is more intuitive.

No functional change intended.

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

sound: Define SNDBUF_F_MANAGED as 0x00000001

It's the only flag anyway.

No functional change intended.

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Reviewed by:    markj, emaste
Differential Revision:  https://reviews.freebsd.org/D53521

sound: Retire unused sndbuf_dump()

Fixes:          https://cgit.freebsd.org/src/commit/?id=e4e61333ffa4e90360de2dd1e4e0146f7cbf0afb
Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Reviewed by:    markj, emaste
Differential Revision:  https://reviews.freebsd.org/D53522

sound: Retire unused sndbuf_getflags() and sndbuf_setflags()

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

sound: Simplify sndbuf_clear() loop

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

sound: Remove redundant sndbuf_free() in chn_kill()

If b exists, it will get destroyed by sndbuf_destroy() (which calls
sndbuf_free()) a few lines below, so the additional sndbuf_free() here
is redundant.

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

sound: Get rid of useless sndbuf getters and setters

No functional change intended.

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

sound: Add to pcm/buffer.* copyright

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week

sound: Retire unused {pcm_feederdesc,feedertab_entry}->idx

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

sound: Retire MAXFEEDERS and feedercnt

Apart from the fact that it's unrealistic to reach MAXFEEDERS (256),
since sound(4) comes with maximum 7 feeders (including feeder_root),
there is also no reason to cap it.

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

sound: Remove unnecessary pcm/vchan.h include from pcm/feeder.c

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

sound: Simplify pcm_feederdesc initialization

Currently we initialize a pcm_feederdesc array for every feeder, which
is then used by FEEDER_DECLARE(). However, there is no reason for this
to be an array, as each feeder has only one description. Additionally,
since the only thing we define in that array is the feeder type, remove
the pcm_feederdesc definitions altogether, and instead pass their type
to FEEDER_DECLARE() directly, which will then initialize the
pcm_feederdesc.

This also simplifies feeder_register().

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

sound: Retire unused pcm_feederdesc->flags

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

sound: Simplify feeder_getclass()

With the parameters we provide feeder_getclass(), the only thing we
really care about is the feeder's class type. We can simplify (and make
the code more readable) that by simply passing the type to
feeder_getclass(). Apart from being simpler, we can now also retire
feedertab_entry->desc and cmpdesc().

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

sound: Retire feedertab_entry

Have an SLIST of feeder_class directly. This way we simplify the code,
and also avoid the additional malloc()/free() for each entry.

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

sound: Retire feeder_class->data

It's always NULL. No functional change intended.

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

sound: Retire feeder_class->desc

The only field we care about is pcm_feederdesc->type, so keep that one
only and do not embed the whole pcm_feederdesc.

While here, make the feeder type enum into a named one and use it as
feeder_class->type's type.

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

sound: Retire pcm_feederdesc->type

This is always accessed from pcm_feeder->desc->type. Instead of
duplicating this field, we can remove it from pcm_feederdesc, and access
it through pcm_feeder->class->type.

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

sound: Remove unnecessary initializations in feeder_create()

We do not need to zero out fields since the struct is allocated with
M_ZERO. Also we no longer need to have a special case for the root
feeder.

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

sound: Retire unused feeder_printchain()

We can print it with "sndctl feederchain".

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

sound: Retire feeder_register_root()

We can now use feeder_register().

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

sound: Retire DSP_DEFAULT_SPEED

Only a few drivers use this, but this is not really our "default" speed.
And even those drivers most likely override that value at some point
once CHANNEL_SETSPEED() has been called.

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

sound: Retire unused SCF_SYNTH

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week

In preparation for further MFP key work, migrate iwx away from using
IEEE80211_KEY_GROUP and pointer arithmetic.  This is a hold over from
ye olde days.

Locally tested:

* (STA mode, CCMP/CCMP network)
* iwx0: <Wi-Fi 6 AX210> mem 0x84c00000-0x84c03fff at device 0.0 on pci4

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

Add this so it can be consumed/graphed.

Differential Revision:  https://reviews.freebsd.org/D53633
Reviewed by:    gallatin, imp

The driver communicates with the AMD IOMMU by writing to the tail of a
fixed length command ring buffer. After issuing cmd_max commands, the
tail pointer wraps back to the beginning of the ring buffer. Now, each
command buffer entry will contain content from previous commands which
may set bits in fields marked as Reserved for the current command. In
some cases, the hardware will return an ILLEGAL_COMMAND_ERROR event when
this occurs.

Fix is to memset the command buffer prior to use.

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270966
Reviewed by:    corvink, kib, markj
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D53692

When VHE mode is enabled, this results in a hang on the host.  In
particular, when MDSCR_EL2.KDE is set to 1 and the CPU is executing at
EL_D, i.e., EL2, debug exceptions are enabled. In non-VHE mode, we call
into the guest by trapping to EL2, which implicitly masks debug
exceptions by setting PSTATE.D. However, in VHE mode, PSTATE.D remains
clear, so when the guest's MDSCR_EL1 value is loaded, we immediately
begin single-stepping.

In non-VHE mode there is no need to set KDE either, so just stop setting
it.

Reviewed by:    andrew
MFC after:      3 days
Sponsored by:   CHERI Research Centre (EPSRC grant UKRI3001)
Differential Revision:  https://reviews.freebsd.org/D48965

TDE (make EL2 the target EL for debug exceptions) is set both when
setting guest breakpoints and when single-stepping the guest.  In some
cases we may configure both capabilities, and when subsequently
disabling one of them we need to take care to avoid clearing TDE if the
other is still configured.

MFC after:      3 days
Fixes:          https://cgit.freebsd.org/src/commit/?id=75cb949228bb ("arm64/vmm: Add breakpoint and single-stepping support")
Sponsored by:   CHERI Research Centre (EPSRC grant UKRI3001)

Retire pccard(4)

pccard has been declared obsolete for a long time and also the
support has been removed but the man page still exists. It mentions
being scheduled to be removed before 13.0 but it still exists in the
tree.

[Extracted from review D53434]

Reviewed by: emaste
Fixes: https://cgit.freebsd.org/src/commit/?id=31b35400c ("pccard: Remove more of the PC Card infrastructure")

pccard.4: Really remove

Fixes:          https://cgit.freebsd.org/src/commit/?id=5b9fba1cb (Retire pccard(4))
Fixes:          https://cgit.freebsd.org/src/commit/?id=31b35400c (Remove more of the PC Card infrastructure)
Discussed with: emaste, jhb

This will be used by the SPE driver.

(commit message by andrew@)

Reviewed by:    andrew
Sponsored by:   Arm Ltd

This will be used by the SPE driver.

(commit message by andrew@)

Reviewed by:    andrew
Sponsored by:   Arm Ltd

arm64: Add Arm SPE support

Add support for the Arm Statistical Profiling Extension (SPE). This
is an optional extension added in Armv8.1 to provide profiling of
software using randomised instruction sampling.

This adds the initial driver, and attached it to the hardware tracing
framework, hwt(4), in CPU mode to allow tracing of all threads on
a given CPU.

(commit message by andrew@)

Co-authored-by: Sarah Walker <sarah.walker2@arm.com>
Co-authored-by: Andrew Turner <andrew@FreeBSD.org>
Reviewed by:    andrew
Sponsored by:   Arm Ltd
Sponsored by:   The FreeBSD Foundation (early driver)
Differential Revision:  https://reviews.freebsd.org/D46241

arm64/spe: Fix the GENERIC-NODEBUG build

Fixes:  https://cgit.freebsd.org/src/commit/?id=68f185ccc9f8 ("arm64: Add Arm SPE support")

If the connection flowid is available then the replies are requested on
the rx queue that is receiving wire traffic for the connection.  This
reduces contention for the txq lock.

Reviewed by:    jhb
MFC after:      3 days
Sponsored by:   Chelsio Communications
Differential Revision:  https://reviews.freebsd.org/D53385

- Simplify directory and file structure.
- Clean up and improve code. Add more comments.
- Add polling examples.

MFC after:      1 week
Reviewed by:    christos
Differential Revision:  https://reviews.freebsd.org/D53353

No functional change intended.

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Reviewed by:    markj, emaste
Differential Revision:  https://reviews.freebsd.org/D53696

Tested with SR8 and DR4 transceivers.

MFC after:      1 week
Sponsored by:   Chelsio Communications

- Avoid some more registers with read side-effects during regdump.
- mps_tcam_size is 3x the size of T6/T5.
- Update rss_rd_row to work with T7.

Obtained from:  Chelsio Communications
MFC after:      1 week
Sponsored by:   Chelsio Communications

apmconf(8) was merged into apm(8) back in 2000 and this note and MLINK
were added as a transition aid, but that aid is no longer needed.

Sponsored by: The FreeBSD Foundation
MFC after:      1 week

sound: Retire unused mixer functions

No functional change intended.

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week

sound: Move mixer->modify_counter to more appropriate place

No functional change intended.

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week

sound: Retire OLDPCM_IOCTL

It is defined by default, and there is no reason to have a switch for
it. While here, also get rid of some unnecessary comments and ioctl
definitions.

No functional change intended.

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week

sound: Remove unnecessary uio checks in dsp_io_ops()

uiomove_faultflag() takes care of that already.

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Reviewed by:    kib
Differential Revision:  https://reviews.freebsd.org/D53733

sound: Do not use double pointer in dsp_io_ops()

No reason to do so.

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Reviewed by:    kib
Differential Revision:  https://reviews.freebsd.org/D53734

sound: Retire SND_DIAGNOSTIC PCM locking macros

Disabled by default, but also redundant, since most of the errors they
catch will be caught anyway by WITNESS and the locking subsystem.

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Reviewed by:    kib
Differential Revision:  https://reviews.freebsd.org/D53735

Cast &end to vm_offset_t before subtracting VM_MIN_KERNEL_ADDRESS to
ensure the resulting size is correct for PRELOAD_PUSH_VALUE.
Previously the correct size was effectively divided by sizeof(void *).

Reviewed by:    andrew
Obtained from:  CheriBSD
Differential Revision:  https://reviews.freebsd.org/D53699

cxgbe(4): Expanded interrupt handling for T7

- Catch up with the new cause/perr registers.  The high level approach
  is the same but the T7 has an extra top level INT_CAUSE concentrator
  and a PERR_CAUSE concentrator with a changed layout.

- Add various flags to control the interrupt handlers' behavior.

- Implement a t4_intr_clear that internally use the slow handler as an
  iterator over known cause/perr registers.  This lets the driver clear
  all of the interrupt sources that it knows about.  The firmware sets
  up the interrupt enables and clears the causes normally so this call
  should be redundant.

MFC after:      1 week
Sponsored by:   Chelsio Communications

cxgbe(4): Skip non-existent blocks in the interrupt handler

Fixes:  https://cgit.freebsd.org/src/commit/?id=7b80c8b7d8d9 cxgbe(4): Expanded interrupt handling for T7
MFC after:      1 week
Sponsored by:   Chelsio Communications

Reported by: np
Fixes: https://cgit.freebsd.org/src/commit/?id=9349214a2815 mlx5: Preallocate ktls tags asynchronously
Sponsored by: Netflix

Migrate to the ieee80211_crypto_key_*() routines.
Should be no functional change.

Locally tested:

* RTL8821AU, STA mode

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

* constify mtw_write_region_1()'s data field
* convert to use ieee80211_crypto_get_*()
* .. note that rx/tx mic data routines are explicitly being called,
  as this NIC is doing TKIP + MIC offload

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

iwx: clean up debugging around key add/set; comments on delete

* Add IWN_DEBUG_KEYMGMT as a debug flag
* Convert DPRINTF(()) in key add/set to IWN_DPRINTF()
* printf() -> net80211_vap_printf()
* add braces around return value

Differential Revision:  https://reviews.freebsd.org/D53703
Reviewed by:    thj

iwx: fix and clean up suspend/resume path

I noticed a couple of things were happening:

* during suspend, I'd get a timeout in the NIC lock path (which
  sets a bit on the NIC to say that the host wants to talk to it);
* resume wouldn't come back - scan commands would fail, and you'd have
  to reinit the NIC again for it to work.

The thing is:

* the suspend path should already shut down the NIC by shutting down all
  the VAPs (and the last VAP should call ic_parent to bring it down), and
* the resume path should already bring up the NIC by bringing up each VAP,
  and the first VAP to be brought up calls ic_parent to bring it up.

So instead, I've shuffled around the code to just double check the
hardware state is consistent /before/ ieee80211_suspend_all() and
ieee80211_resume_all() is called.

This both fixes the errant hardware timeout during suspend, and it
fixes resume to work.

Locally tested:

* AX210, STA mode, both hardware ACPI suspend/resume and devctl suspend
  and devctl resume

Differential Revision:  https://reviews.freebsd.org/D53721
Reviewed by:    thj

iwx: clean up TX AMPDU session establishment and checking

* Send a TX A-MPDU exchange successfully; we were allocating the
  A-MPDU TX queue but returning 0 to net80211 was telling it
  to not establish the TX A-MPDU session and none of the BA session
  tracking stuff would work.

* Clean up the TX A-MPDU queue lookup in the transmit path - only
  QoS data frames are allowed, not qos null-data, cf/ack/etc frames;
  only send them if the A-MPDU session is established.

* Tell net80211 that we've established the TX A-MPDU session once
  the firmware queue has been created.

* Check to make sure we're not double (or more) creating TX AMDPU
  sessions - only allocate a qid if we're not doing A-MPDU yet.

* Delete IWX_FLAG_A-MPDUTX - it's now being properly tracked!

Locally tested:

* AX210, STA mode - gets 50/50mbit on 2GHz HT20, and 100/100mbit on
  5GHz VHT/40.

Differential Revision:  https://reviews.freebsd.org/D53725
Reviewed by:    thj

PR:           https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289121
Reported by:    Qiu-ji Chen
MFC after:      1 week
Sponsored by:   Chelsio Communications
Differential Revision:  https://reviews.freebsd.org/D52199

Some TPM implementations have a different start method that requires
an additional notification for some state changes; for instance, the
"Pluton" start method.  Just factor these transitions out for now, and
the coming commits will introduce points that the start method can hook
in at.

Reviewed by:    obrien
Differential Revision:  https://reviews.freebsd.org/D53682

Reviewed by:  imp, jhb
Differential Revision:  https://reviews.freebsd.org/D53759

Create efi-freebsd.h, which is safe to include from the FreeBSD context
(all of userland, except the small bits we share with edk2 and the
kernel). This defines anything that we need. At the moment, it just
includes NULL definitions.

Create efi-edk2.h, which is approximately ProcessorBind.h from edk2 that
we can include in FreeBSD compontents that are re-using edk2 components
(bits of the boot laoder, and libefi*). Update the efi_gid definitions
to match edk2 better. Add this file to badfiles.inc, since we can't
write it in a way that's compatible. This is copied from the old
efi-osdep.h.

This has to be done in one commit that's bigger than I like since we
can't easily move things piecemeal around they are so inter-related.

Sponsored by:           Netflix
Differential Revision:  https://reviews.freebsd.org/D53651

Add some accessors to the key data, key length and MIC data.
Document exactly what these mean.

There's at least a couple of drivers that access the key data field
directly and assume that the TX/RX MIC is available directly after the
data pointer, which bakes in the "key size is 128 bits" in subtle ways.

The goal here is to migrate the drivers and net80211 code to use
these methods rather than accessing wk_key directly and making assumptions
about wk_key and the copied key length (which the ioctl path definitely
does.)

Once that's done, it should be a lot easier to change the key API for
larger keys.

Differential Revision:  https://reviews.freebsd.org/D52711
Reviewed by:    thj

Remove prefetching from the transmit path of iflib in the interest of
increased performance and reduced complexity. Details regarding the
performance penalties of prefetching can be found in the differential
review.

Note this prefetching was only done on link speeds of 10Gb/s and
above, so the change is a no-op (or perhaps slight performance
improvement simply due to the code simplification) for slower
interfaces.

Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D53674
Reviewed by: kbowling, markj, mjg

if_media.h: Add 400GBase-SR8 and 400GBase-CR8

Reviewed by:    bz (network)
MFC after:      1 week
Sponsored by:   Chelsio Communications
Differential Revision:  https://reviews.freebsd.org/D53387

Fix typo in recently added 400G media

Reported by:    glebius
Fixes:  https://cgit.freebsd.org/src/commit/?id=2d608a4cebbd if_media.h: Add 400GBase-SR8 and 400GBase-CR8
MFC after:      1 week
Sponsored by:   Chelsio Communications

In a divert setup pf_test_state() may return PF_PASS, but not set the state
pointer. We didn't handle that, and as a result crashed immediately afterwards
trying to dereference that NULL state pointer.

Add a test case to provoke the problem.

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260867
MFC after:      2 weeks
Submitted by:   Phil Budne <phil.budne@gmail.com>
Sponsored by:   Rubicon Communications, LLC ("Netgate")

The register address of link length of copper or active cable is 146 as
per the SFF-8436 specification [1].

[1] 7.6.2 Upper Memory Map Page 00h SFF-8436 Specification (pdf): https://members.snia.org/document/dl/25896

Reviewed by:    imp, zlei
MFC after:      1 week
Pull Request:   https://github.com/freebsd/freebsd-src/pull/1885
Closes:         https://github.com/freebsd/freebsd-src/pull/1885

- Report overly long OEM string as too long, not just "bad".

- Use warn instead of warnx for open or ftruncate failure to report the
error string.

Reviewed by:    se
Sponsored by:   The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D53649

PR:                   https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289306
Sponsored by:           Netflix
Reviewed by:            dab
MFC After:              5 days
Differential Revision:  https://reviews.freebsd.org/D52500

Sponsored by: The FreeBSD Foundation
MFC after:      1 week
Reviewed by:    imp, markj, emaste
Differential Revision:  https://reviews.freebsd.org/D53616

Sponsored by: The FreeBSD Foundation
MFC after:      1 week
Reviewed by:    imp, markj, emaste
Differential Revision:  https://reviews.freebsd.org/D53617

If we request a /dev/dsp virtual_oss(8) device, we have to replace the
sound(4) one by first disabling hw.snd.basename_clone. This sysctl tells
sound(4) to not create the /dev/dsp alias for the default device. There
are currently two issues with the way this is handled by virtual_oss(8),
however:

1. It uses system(3) instead of sysctlbyname(3).
2. It does not restore hw.snd.basename_clone to its original value, so
   if prior to virtual_oss(8) running, hw.snd.basename_clone was enabled
   (which is the case by default), and it is closed at some point,
   hw.snd.basename_clone stays disabled, which is annoying, because
   users have to manually restore it, otherwise applications that open
   the default device (i.e., most) will not work.

Fix both issues.

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

This is consistent with other operating systems and with bsdinstall's
UFS config and with bsdinstall's ZFS config prior to commit
0b7472b3d8d2.

Fixes: https://cgit.freebsd.org/src/commit/?id=0b7472b3d8d2 ("Mount the EFI system partition (ESP) on newly-installed systems.")
Reviewed by:    imp
Sponsored by:   The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D53642

The existing parser was needlessly complicated and wildly inconsistent
in how it handled invalid input.  Rewrite using getline() and treat
invalid input consistently: silently ignore lines that don't begin with
a number, and print a warning if the inode number is out of range.

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290992
MFC after:      1 week
Reviewed by:    obrien
Differential Revision:  https://reviews.freebsd.org/D53726

The keys used for pkgbase signing are going to be placed in
/usr/share/keys/pkgbase-N where N is the FreeBSD major version
number; as such it's not sufficient to copy /usr/share/keys/pkg
into the install chroot, but instead we need /usr/share/keys/*.

With hat:       re
MFC after:      8 hours (needed in 15.0-RC1)
Differential Revision:  https://reviews.freebsd.org/D53753

For BETA/RC/RELEASE builds, fetch files from the appropriate repository
on pkgbase.freebsd.org, using the appropriate signing keys.  Note that
there is a separate repository for each BETA and RC; this ensures that
someone installing from e.g. a 15.0-RC1 ISO will get 15.0-RC1 bits and
not whatever happens to be the most recent build from releng/15.0.

With hat:       re
MFC after:      8 hours (needed in 15.0-RC1)

When installing e.g. 15.0-RC1, we want to get files from the 15.0-RC1
pkgbase repository; but running 'pkg upgrade' after installation should
get the latest bits build from releng/15.0.

With hat:       re
MFC after:      8 hours (needed in 15.0-RC1)

On -CURRENT and -STABLE this gets bits from pkg.freebsd.org; but we get
base system bits from pkgbase.freebsd.org for BETA/RC/RELEASE.

Note that this repository is disabled by default, but can still be used
by explicitly specifying it, e.g. "pkg upgrade -r FreeBSD-base".

With hat:       re
MFC after:      8 hours (needed in 15.0-RC1)

When performing a pkgbase install, create a configuration file in
/usr/local/etc/pkg/repos/FreeBSD.conf which enables the FreeBSD-base
repository.  (This repository is defined in /etc/pkg/FreeBSD.conf as
being disabled by default.)

Reported by:    Mark Millard
Reviewed by:    markj
MFC after:      immediately (needed for 15.0-RC1)
Differential Revision:  https://reviews.freebsd.org/D53777

This follows what Illumos has done.

Sponsored by:           Netflix
Reviewed by:            tsoome
Differential Revision:  https://reviews.freebsd.org/D53656

Sponsored by:         Netflix
Differential Revision:  https://reviews.freebsd.org/D53652

Remove the old EFI SDK files that we've been nursing along for too many
years. Replace them with files from EDK2 edk2-stable202502 and tweak the
interfaces we need to tweak. Mostly include different things or change
the names of the protocols that no longer have old-school compat names.

I gave up in the middle of env.c, too damn tedious to find all those new
GUIDs. Also, many of the guids were mystery meat, most likely from the
EDK2 sources, but just not the Include subdirectory. Need to investigate
those. And the memory info? Is it just an oboslete thing, or embedded
knowledge of EDK2.

Delete the now-redundant copies of things in Guid and Protocol. I
debated keeping ZeroGuid.h, but EDK2 has moved on from when I snagged it
years ago (or maybe I just invented it out of whole cloth: edk2 does
radically different things today and I didn't do the git deep-dive to
find out).

Sponsored by:           Netflix
Differential Revision:  https://reviews.freebsd.org/D53655

This new function computes the alignment of a pointer.
It is part of ISO/IEC 9899:2024, the new C standard.
If the pointer is a null pointer, null is returned.
I have tried to write an implementation that can cope
with traditional address-based architectures, even if
size_t and uintptr_t are of different length.  Adjustments
may be needed for CHERI though.

A man page is provided, too.  No unit test for now.

Reviewed by:    kib, imp, ziaee (manpages), pauamma@gundo.com
Approved by:    markj (mentor)
MFC after:      1 month
Relnotes:       yes
Differential Revision:  https://reviews.freebsd.org/D53673

Since the introduction of permission masks, cd9660_getattr() returns a
size of zero for all symbolic links, because the code to retrieve the
length of the link target (as required by POSIX) is dead, since we strip
away the type bits before we try to use them to identify the file as a
link.  Address this by checking the vnode type instead.

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290556
MFC after:      3 days
Fixes:          https://cgit.freebsd.org/src/commit/?id=82f2275b73e5 ("https://cgit.freebsd.org/src/commit/?id=cd9660: Add support for mask,dirmask,uid,gid options")
Reviewed by:    olce
Differential Revision:  https://reviews.freebsd.org/D53598

* When fast-forwarding through a zstd frame, we incorrectly used the
  min() inline function instead of the MIN() macro.  The function
  truncates the result to unsigned int, resulting in a decompression
  error when trying to seek more than 4 GB into the frame.

* POSIX states that a size extended header record overrides the size
  field in the header if present, and that one must be included if the
  size of the file exceeds 8 GB (the size field maxes out at 64 GB).

* Reduce repetition in the exthdr parser by deduplicating the syntax
  error handler.

MFC after:      1 week
Sponsored by:   Klara, Inc.
Fixes:          https://cgit.freebsd.org/src/commit/?id=69d94f4c7608 ("Add tarfs, a filesystem backed by tarballs.")
Reviewed by:    allanjude
Differential Revision:  https://reviews.freebsd.org/D53718

If devfs_set_cdevpriv() fails, we will panic when we enter the
cuse_client_free() callback, for a number of reasons:

- pcc->server is not yet assigned, so we'll use a NULL pointer.
- pcc has not yet been added to the pcs->hcli TAILQ, but we'll try to
  remove it.
- pccmd->sx and pccmd->cv are not yet initializated, but we'll try to
  destroy them.

Even if we'd get past all these somehow, we'd still get two errors in
the devfs_set_cdevpriv() failure block:

- We'll unref the server twice, once in cuse_client_free(), and again in
  cuse_client_open().
- A double-free panic, since we'd be trying to free(pcc), which has
  already been freed in cuse_client_free().

Fix all those issues. While here, also get rid of some unnecessary
devfs_clear_cdevpriv().

Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Reviewed by:    kib
Differential Revision:  https://reviews.freebsd.org/D53708

When starting to scan and ending a scan we clear/set the hardware to
idle.  Similarly we set the hw to idle when we remove the channel
context but when starting we only set it to non-idle when we went from
assoc to run.  This apparently was not a problem most of the time
as the switch from a failed hardware scan to a software scan was
racing against net80211.  ad4ddc83ebf8 fixed that specifically for
rtw88 and while we were more consistently scanning, this broke
authentication as the setting of idle at the end of the scan was
now happening reliably.  Move the unsetting of idle from assoc_to_run
to scan_to_auth for when we  create the chanctx to keep it
symmetrical.  This makes authentication work again for rtw88.

This likely also fixes the problems in the listed PRs.

iwlwifi(4) mvm and mld driver parts do not use this information at
all and were never affected.

Sponsored by:   The FreeBSD Foundation
MFC after:      3 days
Reported by:    Oleg Nauman (oleg.nauman gmail.com)
PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290850, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288186, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281979
PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272145 (the non skb-mem-limit parts)

random: TPM_HARVEST should have been named RANDOM_ENABLE_TPM

* Enable RANDOM_ENABLE_TPM by default

* The commit of TPM_HARVEST failed to add it to NOTES
  so that the LINT kernel would build the code.

Fixes: https://cgit.freebsd.org/src/commit/?id=4ee7d3b0118c82e651712bb65da53d08e78cd7b1
Reviewed by:    imp
Differential Revision:  https://reviews.freebsd.org/D53460

random: git'o in RANDOM_ENABLE_TPM

Fixes:  https://cgit.freebsd.org/src/commit/?id=3deb21f1a

Reviewed by:  jmg
Sponsored by:   Juniper Networks
Differential Revision:  https://reviews.freebsd.org/D53390

Reported by:  bdrewery
Reviewed by:    bdrewery, markj
Tested by:      bdrewery, pho
PR:     https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290843
Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Differential revision:  https://reviews.freebsd.org/D53624

This patch adds support for unmapped I/O to gzero(4).

Let's consider the following script to illustrate the change in
gzero(4)'s behavior:

```
dd="dd if=/dev/gzero of=/dev/null bs=512 count=100000"
dtrace -q -c "$dd" -n '
    fbt::pmap_qenter:entry,
    fbt::uiomove_fromphys:entry,
    fbt::memset:entry
    /execname == "dd"/
    {
        @[probefunc] = count();
    }
'
```

Let's run that script 4 times:

```
==> 1: unmapped I/O not supported (fallback to mapped I/O), kern.geom.zero.clear=1
51200000 bytes transferred in 1.795809 secs (28510829 bytes/sec)
  pmap_qenter                                                  100000
  memset                                                       400011

==> 2: unmapped I/O not supported (fallback to mapped I/O), kern.geom.zero.clear=0
51200000 bytes transferred in 0.701079 secs (73030337 bytes/sec)
  memset                                                       300011

==> 3: unmapped I/O supported, kern.geom.zero.clear=1
51200000 bytes transferred in 0.771680 secs (66348750 bytes/sec)
  uiomove_fromphys                                             100000
  memset                                                       300011

==> 4: unmapped I/O supported, kern.geom.zero.clear=0
51200000 bytes transferred in 0.621303 secs (82407407 bytes/sec)
  memset                                                       300011
```

If kern.geom.zero.clear=0, then nothing really changes as no copying takes
place. Otherwise, we see by adding unmapped I/O support we avoid calls to
pmap_qenter(), which was called by GEOM to turn unmapped I/O requests into
mapped ones before passing them for processing to gzero(4).

Reviewed by:    bnovkov, markj
Approved by:    bnovkov (mentor), markj (mentor)
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D52998

Fixes:                https://cgit.freebsd.org/src/commit/?id=31b35400cf77 ("pccard: Remove more of the PC Card infrastructure")

socantrcvmore() and unp_dispose() assume that the socket's socket
buffers are initialized, which isn't the case for listening sockets.

Reported by:    syzbot+a62883292a5c257703be@syzkaller.appspotmail.com
MFC after:      1 week
Reviewed by:    glebius
Differential Revision:  https://reviews.freebsd.org/D53743

No functional change intended.

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

Only i386 has a four-byte alignment for uint64_t, others have
eight-byte alignment.  This causes the structure to mismatch
on armv7 binaries running under aarch64, breaking the aio interface.

Fixes:          https://cgit.freebsd.org/src/commit/?id=3858a1f4f501d00000447309aae14029f8133946
Approved by:    markj (mentor)
Reported by:    Mark Millard <marklmi26-fbsd@yahoo.com>
Discussed with: jrtc27
PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290962
MFC after:      immediately (for 15.0)

unix/stream: fix a race with MSG_PEEK on SOCK_SEQPACKET with MSG_EOR

The pr_soreceive method first scans the buffer holding the both I/O sx(9)
and socket buffer mutex(9) and after figuring out how much needs to be
copied out drops the mutex.  Since the other side may only append to the
buffer, it is safe to continue the operation holding the sx(9) only.
However, the code had a bug that it used pointer in the very last mbuf as
marker of the place where to stop.  This worked both in a case when we
drain a buffer completely (marker points at NULL) and in a case when we
wanted to stop at MSG_EOR (marker points at next mbuf after MSG_EOR).
However, this pointer is not consistent after we dropped the socket buffer
mutex.

Rewrite the logic to use the data length as bounds for the copyout cycle.

Provide a test case that reproduces the race.  Note that the race is very
hard to hit, thus test will pass on unmodified kernel as well.  In a
virtual machine I needed to add tsleep(9) for 10 nanoseconds into the
middle of function to be able to reproduce.

PR:                     https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290658
Reviewed by:            markj
Differential Revision:  https://reviews.freebsd.org/D53632
Fixes:                  https://cgit.freebsd.org/src/commit/?id=d15792780760ef94647af9b377b5f0a80e1826bc

unix/stream: fix instant panic w/o INVARIANTS

A stupid microoptimization I made leaving empty STAILQ inconsistent
is a brainfart that is related to much earlier version of this code,
where it was safe to do so.

Pointy hat to:  glebius
Fixes:          https://cgit.freebsd.org/src/commit/?id=69f61cee2efb1eec0640ca7de9b2d51599569a5d

PR:           https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290812
Fixes:          https://cgit.freebsd.org/src/commit/?id=2ad0f7e91582 ("Import iwx as ported from OpenBSD by Future Crew.")
Reviewed by:    emaste
Differential Revision:  https://reviews.freebsd.org/D53758

Add 64 bit support to vchiq:

 * update fields to the appropriate fixed bit-size variants (everywhere [cf. e.g., ref:sizes and ref:sizes2])
 * refer to event semaphores (that go into the very 32 bit VC) by offset instead of pointers [ref:sems]
 * dsb() is dsb(sy) in arm64 (vchiq_{core.c,core.h,kmod.c}) [ref:dsb]
 * comment out some unneeded code in parse_rx_slots around VCHIQ_MSG_BULK_RX (cf. [ref:deadcode])
 * adapt remote_event_signal to arm64 caching behaviours (vchiq_kmod.c)
 * refactor synchronization around remote_event_signal, forcing a wmb to be on the safe side; thereby make it look more like what linux does [ref:sync] (vchiq_{core,kmod}.c); and make a comment in vchiq_core.c true (wasn't before)
 * add a few more syncs to be on the safe side (vchiq_2835_arm.c)
 * use arm64 dcache invalidation mechanisms (vchiq_2835_arm.c)
 * explicitly invalidate pages on arm64 post bulk-read (vchiq_2835_arm.c)
 * support bulk transfers on rpi-4 (aka "long address space" transfers), by hard-coding their vc offset (0) and different bit-shift [ref:longbulk] (vchiq_2835_arm.c)
 * refactor a loop-of-constant-test (vchiq_2835_arm.c)
 * use the correct (hard-coded) cache-line size on arm64
 * rework the handling of chipset "features" to account for the extra behaviours with 64 bit chipsets. (vchiq_kmod.c)
 * add sysctl-s (log, arm_log) to control debug (vchiq_kmod.c)
 * add example kernel config (GENERIC-VCHIQ)

Fixes:

 * Rework error handling in create_pagelist, avoiding a potential panic when
   freeing memory that had been dmamem_alloc, a potential null dereference,
   and a leak when having problems pinning pages (vchiq_2835_arm.c)
 * fix a confusion about the behaviour cv_wait_sig that lead to
   uninterruptible looping (vchiq_bsd.c)
 * implement detection of fatal signals (vchiq_bsd.c)
 * fix a confusion with the name of a variable introduced by #a0b8746
   that could lead to a panic when closing the cdev file (vchiq_arm.c)
 * release user connection when destructing cdevpriv and avoid user processes
   sharing connection data, which lead to stalls and data corruption. (vchiq_arm.c)

Update bcm2835_audio to work on 64bit systems:

 * update VC audio fields (vc_vchi_audioserv_defs.h, bcm2835_audio.c)
 * repurpose the hitherto unused callback field to help push a 64 bit pointer in (bcm2835_audio.c)
 * increase (hopefully) the robustness of the code that shifts data to VC (bcm2835_audio.c)
 * add a sysctl to control the amount of debugging info output by bcm2835_audio.c

Tested on zero, zero2 and 4+ with ping, functional, bulk and control vchiq_test-s, and omxplayer

  [ref:dsb]: https://github.com/raspberrypi/linux/commit/35b7ebda57affcfd3616d39d5a727a4495b31123
  [ref:sems]: https://github.com/raspberrypi/linux/commit/24a4262afb10907fce3cdbc3ae336fcf4cdaece5
  [ref:sizes]: https://github.com/raspberrypi/linux/commit/e64568b8ea6c04e747e432c17ce2452652075216
  [ref:sizes2]: https://github.com/raspberrypi/linux/commit/f9bee6dd24addfa00c2c8d50c25b73efbfbb28ba
  [ref:deadcode]: https://github.com/raspberrypi/linux/commit/14f4d72fb799a9b3170a45ab80d4a3ddad541960
  [ref:sync]: https://github.com/raspberrypi/linux/commit/51c071265079319583e4c6e8c61e09660300d0bf
  [ref:longbulk]: https://github.com/raspberrypi/linux/commit/37f6f19a83722c9b866cecb5e455b2e16e5bbc6b

Differential Revision:  https://reviews.freebsd.org/D37878
Submitted by: Marco Devesas Campos <devesas.campos@gmail.com>

For 32-bit processes on 64-bit architectures, a difference of 'int'
pointers was wrongly used as a number of bytes to copy in a memcpy()
used to internally construct a 64-bit 'struct setcred' from the 32-bit
variant, leading to copying only part of the 32-bit structure, and thus
to requesting credentials with garbage IDs except for the real and
effective user IDs.

This bug was spotted by jhb@, who produced a slightly more invasive fix
in D53757 (a switch to using CP() on all fields).  In the interest of
minimizing the diff for possible inclusion in 15.0, the commit here just
limits itself to fixing the number of bytes to copy.

Tested successfully on a VM with 32-bit mdo(1) (and in passing also
tested that the same executable on a kernel without this change exhibits
the bug in practice, in the form of setcred() failing with EINVAL).

Reported by:    jhb
Reviewed by:    jhb
Fixes:          https://cgit.freebsd.org/src/commit/?id=ddb3eb4efe55 ("New setcred() system call and associated MAC hooks")
MFC after:      3 days
Sponsored by:   The FreeBSD Foundation
Differential Revision:  https://reviews.freebsd.org/D53767

For 15.0, apply a minimal fix which at least ensures that inotify can't
trigger the latent race described in commit 99cb3dca4773 ("vnode: Rework
vput() to avoid holding the vnode lock after decrementing").

Reviewed by:    olce, kib
MFC after:      3 days
Differential Revision:  https://reviews.freebsd.org/D53774

Consider a program that creates a unix socket pair, transmits both
sockets from one to the other using an SCM_RIGHTS message, and then
closes both sockets without externalizing the message.  unp_gc() is
supposed to handle cleanup, but it is only triggered by uipc_detach(),
which runs when a unix socket is destroyed.  Because the two sockets are
internalized, their refcounts are positive, so uipc_detach() isn't
called.

As a result, a userspace program can create an unbounded amount of
garbage without triggering reclaim.  Let's trigger garbage collection
whenever a unix socket is close()d.  To implement this, add new a
fdclose file op and protocol op, and implement them accordingly.  Since
mqueuefs has a hack to hook into the file close path, convert it to use
the new op as well.

Now, userspace can't create garbage without triggering reclamation.

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

These are user-facing manpages, but were installed in the runtime-dev
package since the PAM modules use bsd.lib.mk.  Use MANNODEV instead of
MAN to put them in the base runtime package instead.

Fixes:  https://cgit.freebsd.org/src/commit/?id=031e711647c3 ("packages: Install development manpages in the -dev package")
MFC after:      3 days
Reviewed by:    bapt
Sponsored by:   https://www.patreon.com/bsdivy
Differential Revision:  https://reviews.freebsd.org/D53601

OpenPAM is a discrete, largely self-contained system component.
Users may not need PAM for many use-cases (e.g. jails, containers),
so move it to its own package.

Use LIB_PACKAGE to create a separate pam-lib package for libpam,
so that applications that support PAM don't need to bring in all
the PAM modules if PAM isn't actually in use.

Add pam to the minimal sets, since this is a core system component that
people expect to be installed.  This means all supported installation
methods will install the PAM modules by default, so don't add explicit
dependencies on the PAM modules from things that use PAM (e.g. runtime),
allowing custom/embedded systems to omit these easily.

This change adds a new package to the system so, until we have a proper
policy on how to handle this in release/stable branches, it should not
be MFC'd.

MFC after:      never
Reviewed by:    des, bapt
Sponsored by:   https://www.patreon.com/bsdivy
Differential Revision:  https://reviews.freebsd.org/D53602

We need to specify the correct image names -- *.vhdf, not *.vhd -- in
order for them to upload.

15.0 candidate

Reviewed by:    lwhsu
MFC after:      2 days
Differential Revision:  https://reviews.freebsd.org/D53684

Fixes:        https://cgit.freebsd.org/src/commit/?id=6efcc2f26ab0 Add static tracing for privilege checking
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D53630

pcic.4: Remove stale manual

MFC after:      2 days
Reviewed by:    ziaee
Fixes:          https://cgit.freebsd.org/src/commit/?id=31b35400c (pccard: Remove more of the PC Card)
Discussed with: bsdimp, emaste, jhb
Extracted from: https://reviews.freebsd.org/D53434

pcic.4: Really remove

MFC after:      2 days
Fixes:          https://cgit.freebsd.org/src/commit/?id=1d9f2db7c (pcic.4: Remove stale manual)
Fixes:          https://cgit.freebsd.org/src/commit/?id=31b35400c (pccard: Remove more of the PC Card)
Reported by:    emaste

MFC after:    1 week
Fixes:          https://cgit.freebsd.org/src/commit/?id=d2870b8666f2 ("queue: Add atomic variants for *_EMPTY")

With help from:       mckusick
Reviewed by:    emaste, pauamma_gundo.com
Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Differential revision:  https://reviews.freebsd.org/D53589

Rather than superscript <sup>, for a nicer looking list.

Reviewed by:    vexeduxr
Sponsored by:   The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D53000

The intention was clearly that these ACPI bits would be included for
arm64, but MACHINE_ARCH there is aarch64 -- correct the minor typo to
build everything that should be there.

Fixes:  https://cgit.freebsd.org/src/commit/?id=c2e9c5bbf0229 ("tpm: Refactor TIS and add a SPI attachment")

We need to preserve modification times on bootstrap tools, but `cp -p`
also tries to preserve flags, which fails if OBJROOT is on NFS.  A -N
option was added to cp for this purpose, but trying to use that would
break cross-building on hosts that don't have that option.  The best
remaining option is `install -p`, which we already assume is present.

PR:             https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030
Reviewed by:    imp, emaste
Differential Revision:  https://reviews.freebsd.org/D53751

GCE image family is meant to be unique per set of image characteristics
so that a user can create instances using the image family instead of the
image name to reliably get a similar image with updated software, but no
other changes.

Without this change, the instances create API would select the most recent
non-deprecated image matching the name, regardless of architecture or
filesystem.

GCE: Specify the architecture of images

Without a specified architecture, a user can attempt to create an
arm64 instance with an amd64 image or vice versa. With the change
the API will prevent that mismatch.

GCE: Don't .error on unsupported targets

We ingest Makefile.gce even when we're not trying to create GCE images
so we don't want to .error here.  Instead, set GCE_ARCH to a dummy
value which should make the problem clear to anyone who attempts to
create GCE images on an unsupported architecture.

Reported by:    Jenkins
Fixes:          https://cgit.freebsd.org/src/commit/?id=0a8ecca4e315 ("GCE: Specify the architecture of images")

We were doing this in vm_extra_install_packages but VM images without
any extra packages installed would not get this installed.  This
results in a pkgbase system which thinks it doesn't have any packages
installed (even though all the files are right there).

Add a "metalog_add_data ./var/db/pkg/local.sqlite" call to the pkgbase
install code path, and make the call from vm_extra_install_packages
conditional on !PKGBASE.

Reported by:    Michael Dexter
MFC after:      immediately (needed for 15.0-RC1)

vmimage.subr: Enable FreeBSD-base repo if pkgbase

When creating a VM image using pkgbase, create a configuration file in
/usr/local/etc/pkg/repos/FreeBSD.conf which enables the FreeBSD-base
repository.  (This repository is defined in /etc/pkg/FreeBSD.conf as
being disabled by default.)

Reported by:    Mark Millard
MFC after:      immediately (needed for 15.0-RC1)

vmimage.subr: autoremove -y

Running 'pkg autoremove' without -y results in VM image builds failing
when (bogusly installed) packages are removed.

Fixes:  https://cgit.freebsd.org/src/commit/?id=6a13aeac3c1f ("vmimage.subr: pkg autoremove after pkg install")
MFC after:      immediately (needed for 15.0-RC1)

vmimage.subr: Don't log missing files from pkgs

When installing "extra" packages (aka those built from the ports tree),
we record everything being installed in METALOG.pkg; the contents of
that file is appended to METALOG before we generate the filesystem.

There are two cases when files recorded in METALOG.pkg will no longer
exist by the time we create the final disk image:
1. If a pkg bug results in false dependencies being installed which
are later removed by "pkg autoremove", and
2. If the pkg we build and install from /usr/ports is older than the
pkg on pkg.freebsd.org, and pkg gets upgraded automatically as part of
installing extra packages.

The ultimate issue in both cases is that there's no mechanism for
removing entries from METALOG when we run 'pkg delete'.

Address this build breakage by checking, line by line, if filesystem
objects mentioned in METALOG.pkg exist before appending them to METALOG.

Fixes:  https://cgit.freebsd.org/src/commit/?id=6a13aeac3c1f ("vmimage.subr: pkg autoremove after pkg install")
MFC after:      immediately (needed for 15.0-RC1)

vmimage.subr: Log correct paths into METALOG

Paths all need to start with "./" because that's what newfs wants.

Fixes:  https://cgit.freebsd.org/src/commit/?id=e0c41af9256b ("vmimage.subr: Enable FreeBSD-base repo if pkgbase")
MFC after:      immediately

We were deleting the .a files for llvm when it was build in bootstrap,
but this caused us to rebuild all the bootstrap things since the
bootstrap compiler changed, making the build time 25 minutes instead of
77 seconds on one of my systems. Items before the last rebuild from
scratch epoch are no longer relevant because you have to rebuild
entirely, so the incremental conditions that lead up to them being
needed are no longer true.

Sponsored by:           Netflix
Reviewed by:            jrtc27, emaste
Differential Revision:  https://reviews.freebsd.org/D53693

Although the epoch is 20250805, the push for that wasn't until 20250814,
so we can remove the 20250813 entry for tcopy, per jrtc27. Also, include
an example of changing a shell script to a binary, since that's
deceptively tricky, though the code looks simple, per emaste.

There should be no functional changes here.

Sponsored by:           Netflix

Fixes:        https://cgit.freebsd.org/src/commit/?id=a38a42ed9a975 (random: remove hifn(4))
Fixes:  https://cgit.freebsd.org/src/commit/?id=685a78570b359 (random: remove hifn(4))

sound tests: Test polling

Co-authored by: meka@tilda.center
Sponsored by:   The FreeBSD Foundation
MFC after:      2 weeks
Reviewed by:    markj
Differential Revision:  https://reviews.freebsd.org/D53188

sound tests: Fix select(2) arguments

Fixes:          https://cgit.freebsd.org/src/commit/?id=dd81b19ef236 ("sound tests: Test polling")
Sponsored by:   The FreeBSD Foundation
MFC after:      1 week

sound tests: Fix format specified for kevent.data

Reported by:    CI
Fixes:          https://cgit.freebsd.org/src/commit/?id=dd81b19ef236 ("sound tests: Test polling")
Sponsored by:   The FreeBSD Foundation
MFC after:      1 week

sound tests: Actually fix format strings

Fixes:          https://cgit.freebsd.org/src/commit/?id=eb95b990f8eb ("sound tests: Fix format specified for kevent.data")

Submitted by: Marco Devesas Campos <devesas.campos@gmail.com>
Differential Revision:  https://reviews.freebsd.org/D37879

On x86 these trigger for 32-bit builds. We only ever (will) do that for
the 32-bit loader that starts a 64 bit kernel for ia32. For the moment,
take the training wheels off, though most likely some compile flags need
to be used to change the i386 ABI to force *int64_t alignment to 64
bits or some other horror as yet ill-concieved. Despite this assertion,
the ia32 to boot 64-bit kernels loaders seem to work.

Sponsored by:           Netflix
Differential Revision:  https://reviews.freebsd.org/D53653

Pull in more headers from edk2-stable202502 that will be needed as we
transition the building to using only EDK2 headers in the boot loader,
finally ditching our home-grown ones from a super-obsolete SDK from the
early days of EFI.

Note to future importers: My apologies if this not being a mege commit
causes problems. Except for ProcessorBind.h, all files should be exactly
as we got them from EDK2, and if that breaks the build on future
imports, we should adjust our code.

Sponsored by:           Netflix
Differential Revision:  https://reviews.freebsd.org/D53654

Bring these in from edk2-stable202502. They will be used in a
forthcoming TPM 2.0 support code.

Sponsored by:           Netflix

vnode: Rework vput() to avoid holding the vnode lock after decrementing

It is not safe to modify the vnode structure after releasing one's
reference.  Modify vput() to avoid this.  Use refcount_release_if_last()
to opportunistically call vput_final() with the vnode lock held since we
need the vnode lock in order to deactivate the vnode, and it's silly to
drop the vnode lock and immediately reacquire it in this common case.

Note that vunref() has a similar flaw.  D52628 aims to fix the problem
more holistically, but this change fixes observable panics in the
meantime.

Reported by:    syzbot+6676b3ff282d590b0fb3@syzkaller.appspotmail.com
Reported by:    syzbot+38e26cf6f959e886f110@syzkaller.appspotmail.com
Reviewed by:    kib
MFC after:      3 days
Differential Revision:  https://reviews.freebsd.org/D52608

Revert "vnode: Rework vput() to avoid holding the vnode lock after decrementing"

The change can introduce a deadlock if we release the vnode lock in
order to release a reference, and then end up releasing the final
reference after all, requiring a relock of the vnode.  This relock may
violate the usual parent->child vnode lock order.

This reverts commit 99cb3dca4773fe4a16c500f9cb55fcd62cd8d7f3.

Reported by:    jhb