This is a display of mostly-automatically-classified git commits from 2025-11-10 to 2025-11-16.
In the future, these reports might include summaries or additional information, but for now our focus is figuring out what type of classification would be most useful.
Table of contents and commits per category:
| (3) | Highlighted commits (these are copies, not in stats) | |
| 4 | 2.2% | Userland programs |
| 18 | 9.9% | Documentation |
| 79 | 43.6% | Hardware support |
| 6 | 3.3% | Networking |
| 15 | 8.3% | System administration |
| 1 | 0.6% | Libraries |
| 3 | 1.7% | Filesystems |
| 17 | 9.4% | Kernel |
| 21 | 11.6% | Build system |
| 2 | 1.1% | Internal organizational stuff |
| 5 | 2.8% | Testing |
| 2 | 1.1% | Style, typos, and comments |
| 6 | 3.3% | Contrib code |
| 2 | 1.1% | Reverted commits |
| 0 | 0.0% | Unclassified commits |
| 181 | 100% | total |
| Technical notes about this page |
For extra visibility, these are copies of commits found in
other sections. Most (if not all) come from the commit message
containing "Relnotes:", or commits modifying
UPDATING.
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
Commits about commands found in man section 1 (other than networking).
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
Man pages, release notes, etc.
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
Hardware drivers and architecture-specific code.
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
Network-related commands, library, and kernel.
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
Stuff in man section 8 (other than networking).
- 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
Kernel stuff (other than networking, filesystems, and drivers).
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))
These keys were generated by cperciva@ using the AWS Key Management Service. They will not be used for signing anything other than FreeBSD 15.x pkgbase repositories. Keys will be generated for FreeBSD 16 at a later date, and likely in a different way. With hat: re MFC after: 8 hours (needed in 15.0-RC1) Differential Revision: https://reviews.freebsd.org/D53768
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")
These could go in other categories, but it's more clear if they're here instead.
MFC after: 3 days
Submitted by: Marco Devesas Campos <devesas.campos@gmail.com> Differential Revision: https://reviews.freebsd.org/D37879
Have our own ProcessorBind.h. It just includes sys/efi-edk2.h, but undefines TRUE, FALSE and MAC. The first two are from acpica and are redefined to something almost the same. MAC is a global option that, well, interferes with using EDK2, dangit. I suppose I should redefine it after, but I don't think you can save the value of a pre-processor variable. This breaks a little with the tradition of having this in a seprate directory and using build magic. However, the build is already magical enough and having this here makes things less magical. Also, EDK2 puts this in a processor specific directory, so we won't have conflicts (they need it there since they run on more processors than we do: we can just include sys/efi-edk2.h which covers the smallar variance we have in processors). Sponsored by: Netflix
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
Not classified automatically, and waiting for manual attention.
-- no commits in this category this week --
Dates:
Automatic grouping:
This reverts commit \\b([0-9a-fA-F]{40})\\b
and the hash was found in this week's commits.
Automatic categories:
Source code:
Generated with commits-periodical 0.18 at 2025-11-18 01:07:56+00:00.
This work is supported by Tarsnap Backup Inc.
Alternate version: 2025-11-10 (debug) (contains info about the classification)