aboutsummaryrefslogtreecommitdiff
path: root/sys
Commit message (Collapse)AuthorAgeFilesLines
* uvideo: fix step=0 infinite loop and int overflow in fbuf_sizeHEADmainBaptiste Daroussin2026-07-241-1/+3
| | | | | | | | | Prevent infinite loop in uvideo_vs_negotiation() when a USB camera reports step=0 in its continuous frame interval descriptor. Cast fbuf_size calculation to uint64_t to avoid int overflow for large width/height/bpp combinations. Reported by: emaste
* sound: Scale PCM secondary buffers by byte rateKevin Bowling2026-07-243-34/+96
| | | | | | | | | | | | | | | | | | | The fixed 128 KiB secondary buffer cap dates from stereo-sized streams. High channel-count or high sample-width OSS streams can consume most of that budget in one graph quantum, leaving too little room for capture catch-up or playback headroom. Keep 128 KiB as the low-rate floor, but derive the effective soft-ring cap from the channel byte rate, clamped to 4 MiB. Use that per-channel cap when resizing the soft buffer and when clamping SNDCTL_DSP_SETFRAGMENT requests. Also clamp SNDCTL_DSP_LOW_WATER to the current soft-buffer size so an impossible readiness threshold cannot make poll/select wait forever. MFC after: 3 weeks Reviewed by: christos Differential Revision: https://reviews.freebsd.org/D58064
* cuse: Fix server reference leak in cuse_client_open()giacomo2026-07-241-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the server is closing (or the device node is going away), or if devfs_set_cdevpriv() fails, cuse_client_open() returns with the server reference taken at the top of the function still held and the newly allocated client still linked on pcs->hcli. Since cuse_client_free() has not been registered as the cdevpriv destructor at that point, nothing ever undoes this work: every open() that races the is_closing window permanently leaks one server reference and one cuse_client. A leaked reference is fatal on server exit: cuse_server_free() busy-waits in an uninterruptible pause("W", hz) loop until pcs->refs drops to 1, which now never happens, so the exiting server process (e.g. virtual_oss(8)) is left wedged in state "D", immune to SIGKILL, cuse.ko is pinned (kldunload hangs too), and only a reboot recovers. Before 634e578ac7b0 the is_closing error path dropped the reference by calling devfs_clear_cdevpriv(), which ran the cuse_client_free() destructor. That commit moved devfs_set_cdevpriv() after the is_closing check to fix the panic paths, but left both error returns without any cleanup. Fix by calling cuse_client_free() directly on both error paths. The client is fully constructed and linked on pcs->hcli at these points, which is exactly the state cuse_client_free() expects. PR: 296291 Fixes: 634e578ac7b0 ("cuse: Fix cdevpriv bugs in cuse_client_open()") Assisted-By: Claude Opus 4.8 (claude-opus-4-8) Signed-off-by: giacomo <delleceste@gmail.com> MFC after: 2 weeks Reviewed by: christos Pull-Request: https://github.com/freebsd/freebsd-src/pull/2324
* snd_uaudio: Don't let an idle stream reprogram a shared UAC2 clockgiacomo2026-07-241-8/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some UAC2 devices expose a single Clock Source entity that is shared between their playback and capture interfaces (it appears in both the output and input clock bitmaps). On such a device uaudio(4) programs the sample rate for both directions when a stream starts. If playback runs at a 44.1 kHz-family rate while the idle capture channel is left at its 48 kHz-family default, the capture SET_CUR(UA20_CS_SAM_FREQ_CONTROL) is issued after the playback one and overwrites the rate on the shared clock. The device then runs at ~48 kHz while the playback stream carries 44.1 kHz data. Consuming samples faster than they arrive, the device repeatedly runs out of data, loses sync with the playback stream, and re-locks onto it (audible dropouts, front-panel play/idle flicker). The 48 kHz family is unaffected because both directions then agree on the rate. Fix it in three parts: - Add a shared-clock guard: before issuing SET_CUR to a clock id, if that clock is shared between playback and capture and the other direction is already streaming at a different rate, skip it. The first active stream owns the clock; a later one follows it. - When the recording channel is auto-started only as a source of jitter information for asynchronous playback, align its nominal rate to the playback rate before starting it, so it neither reprograms the shared clock to a conflicting rate nor produces mismatched frame sizes. - Always submit the explicit-feedback SYNC transfer so dev.pcm.%d.feedback_rate stays live as a diagnostic even when a capture stream is present. Reproduced on an OKTO RESEARCH DAC8 STEREO (0x152a:0x88c5), whose vestigial capture interface never streams; the same device plays the 44.1 kHz family correctly under Linux's snd-usb-audio. As a side effect, this patch also fixes the sample rate bug mentioned in the BUGS section of sound(4)'s man page, where a device needs to have the same sample rate set for both playback and recording in order to work properly. PR: 295933 Assisted-By: Claude Opus 4.8 (claude-opus-4-8) Signed-off-by: giacomo <delleceste@gmail.com> MFC after: 2 weeks Reviewed by: christos Pull-Request: https://github.com/freebsd/freebsd-src/pull/2323
* icmp: Verify redirect gateway with fib-aware ifa selectionPouria Mousavizadeh Tehrani2026-07-241-2/+1
| | | | | | | | During call to `icmp_verify_redirect_gateway()` ensure using fib-aware source address selection function. Reviewed by: glebius Differential Revision: https://reviews.freebsd.org/D58409
* getpgrp(2), getsid(2): allow to call on zombiesKonstantin Belousov2026-07-231-4/+8
| | | | | | | | | | Also be more protective in getsid(). Reported by: arrowd Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differrential revision: https://reviews.freebsd.org/D58393
* hwpstate_intel(4): use CPU_FOREACH instead of an IPIRyan Libby2026-07-231-17/+7
| | | | | Reviewed by: aokblast, kib, olce Differential Revision: https://reviews.freebsd.org/D58336
* tcp: make ghost ACK handling more conformantMichael Tuexen2026-07-231-1/+1
| | | | | | | | | | | The latest version of draft-ietf-tcpm-tcp-ghost-acks changed a condition. This should make no substantial difference, but makei it compliant to the latest version of the specification. Reviewed by: rscheff, Peter Lei MFC after: 3 days Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D58411
* pf(4) fix NULL pointer dereference in outbound packet path.Kristof Provost2026-07-231-2/+11
| | | | | | | | | | | | | | | | | | | | | | | Outbound packet which matches rule with source limiter attached, for example: source limiter "crash" id 1 entries 10000 limit 1000 pass out from any to any source limiter "crash" keep state triggers a NULL pointer dereference. The issue was kindly reported and initial version of fix submitted by SecBuddyF, Tencent KeenLab. The submitted diff fixed the issue for failing look up by destination address in outbound packet. dlg@ also pointed out the change should be further improved so NULL pointer dereference is avoided when rule uses nat-to/rdr-to option. OK dlg@ Obtained from: OpenBSD, sashan <sashan@openbsd.org>, f0f215c11e Sponsored by: Rubicon Communications, LLC ("Netgate")
* pf: include direction in fragment keyKristof Provost2026-07-231-8/+14
| | | | | | | | | | | | pf(4) currently ignores fragment direction (in vs. out) in pf_frnode_compare() function. Issue noticed and reported by Frank Denis OK @bluhm Obtained from: OpenBSD, sashan <sashan@openbsd.org>, eaa2c80721 Sponsored by: Rubicon Communications, LLC ("Netgate")
* kqueue: Fix delivery of unwanted eventsDag-Erling Smørgrav2026-07-232-5/+5
| | | | | | | | | | | | | | | | | In both procdesc_kqops_event() and filt_proc(), the event variable can have more than one bit set. This means that: * We cannot compare it directly with NOTE_EXIT; we must binary-and them instead. * We cannot binary-or it with the report mask; we must binary-and it with the request mask first. MFC after: 1 week Fixes: 2a5e58c59694 ("procdesc: add NOTE_PDSIGCHLD") Fixes: b328975b9d7c ("procdesc: report NOTE_PDSIGCHLD for traced and stopped process") Reviewed by: kib, markj Differential Revision: https://reviews.freebsd.org/D58395
* if_geneve: Ensure there is no mbuf leak if EAFNOSUPPORTPouria Mousavizadeh Tehrani2026-07-221-0/+1
| | | | | | In practice, this is not possible, but we are adding it just to be safe. Reported by: markj
* uvideo: fix printf typeBaptiste Daroussin2026-07-221-1/+1
| | | | Reported by: vishwin
* uvideo: validate frame descriptors and fix integer overflows in size computationBaptiste Daroussin2026-07-221-44/+70
|
* uvideo: use size_t for sc_mmap_count and loop index in reqbufsBaptiste Daroussin2026-07-221-6/+5
|
* uvideo: fix close/detach race on streaming teardownBaptiste Daroussin2026-07-221-11/+11
| | | | | | | | | | | | detach() stopped streaming and called uvideo_vs_close() before destroy_dev(), so a concurrent close() could race the teardown and call uvideo_vs_close() a second time (double usbd_transfer_unsetup), and mtx_destroy() could race a close still holding sc_mtx. sc_streaming was also read without the lock in both paths. Reorder detach() to call destroy_dev() first so all in-flight cdev methods drain before any teardown. Read sc_streaming under sc_mtx in both detach() and the last-close safety net.
* uvideo: track streaming ownership per-fd and free buffers on STREAMOFFBaptiste Daroussin2026-07-221-3/+76
| | | | | | | | | | | | | The driver shared a single streaming state and buffer pool across all open file descriptors, so a second client (e.g. another browser tab) could disrupt the first: its cleanup STREAMOFF would tear down the active stream, and stale buffers prevented re-acquisition. Add per-fd state via devfs cdevpriv tracking whether this fd started streaming. STREAMOFF and close from a non-streaming fd are no-ops. STREAMOFF from the streaming fd stops the stream and frees the buffers so that a new fd can re-acquire the camera. DQBUF returns EPIPE immediately when buffers are freed instead of waiting for a timeout.
* uvideo: bounds-check frame interval reads against bLengthBaptiste Daroussin2026-07-221-7/+9
| | | | | | | | | | | | | | | Frame interval data is read from device-supplied frame descriptors whose bLength may be shorter than the number of intervals declared by bFrameIntervalType. The continuous branch of uvideo_enum_fivals() read three intervals unconditionally, and the discrete branch checked the pointer but not the four bytes that UGETDW() reads, so a short or malformed descriptor could read past bLength and leak adjacent kernel memory to userspace. uvideo_vs_parse_desc_frame_max_rate() had the same class of off-by-up-to-three-bytes read. Compute the available bytes from bLength and validate before each read. Reported by: emaste
* uvideo: lock the mmap queue and read pathBaptiste Daroussin2026-07-221-13/+59
| | | | | | | | | | | | | | | | qbuf(), dqbuf() and read() manipulated sc_mmap_q / sc_mmap_cur / sc_frames_ready without sc_mtx, racing with the USB transfer callbacks (producer) that run under the mutex. This could corrupt the queue or trigger use-after-free. Take sc_mtx around qbuf(), use mtx_sleep() and protect the queue operations in dqbuf(), and use mtx_sleep() with a snapshot of sc_fsize in read(). Also reject S_FMT and S_PARM with EBUSY while streaming: both re-negotiate the probe/commit controls with the device, which disrupts the active USB transfers (a second client opening the device would otherwise freeze the first one's stream).
* uvideo: validate frame size before mmap buffer allocationBaptiste Daroussin2026-07-221-4/+12
| | | | | | | | | | | | | dwMaxVideoFrameSize comes from the USB probe/commit response and is not validated. reqbufs() computed buf_size_total with signed int arithmetic and no bound, so a bogus value could wrap the product to a small size and yield a too-small buffer with a huge sc_mmap_buffer_size, causing out-of-bounds writes from the USB transfer callbacks. Bound the frame size against sc_max_fbuf_size and use overflow-checked size_t arithmetic for the total and per-buffer offsets. Reported by: emaste
* uvideo: replace contigmalloc with OBJT_PHYS vm_object for mmap bufferBaptiste Daroussin2026-07-221-141/+51
| | | | | | | | | | | | Allocate the mmap buffer via phys_pager_allocate() and map it into kernel space with vm_map_find()/vm_map_wire(), instead of a custom cdev_pager backed by contigmalloc. phys_pager_allocate() is required over a bare vm_object_allocate(OBJT_PHYS) to initialise un_pager.phys.ops, otherwise phys_pager_getpages() NULL-derefs during vm_map_wire(). Reviewed by: markj Reported by: markj Differential Revision: https://reviews.freebsd.org/D58394
* powerpc64: enable extended error strings in GENERIC64* configsSiva Mahadevan2026-07-222-0/+2
| | | | | | | | | | These kernconfs were missed in the previous commit. PR: 289236 Reviewed by: kib Fixes: f38cbefef8090f3363e5685c5a3b30ffbf1d3ad0 MFC after: 3 days Sponsored by: The FreeBSD Foundation
* bind(2): Lookup local address in current FIB if '*.bind_all_fibs' is activeBojan Novković2026-07-224-6/+12
| | | | | | | | | | | | | | | | | | | When a protocol-specific 'bind_all_fibs' tunable is set to 0, a listening socket will only receive traffic originating from the FIB it was bound to. However, there are no checks to determine whether an address exists in the target FIB when binding the socket, which can lead to a situation where a socket and the address it was bound to belong to different FIBs. Prevent this footgun by looking up the requested address in the current FIB if 'bind_all_fibs' is active and returning an error if the address does not exist. Sponsored by: Stormshield Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D58281 Reviewed by: glebius, pouria, markj MFC after: 2 weeks
* tarfs: remove unused 'ino' in mount structure.Philippe Michaud-Boudreault2026-07-221-1/+0
| | | | Differential Revision: https://reviews.freebsd.org/D57898
* exec: Avoid overflow when computing the size of the exec mapMark Johnston2026-07-221-1/+1
| | | | | | | | | On a test system with 1024 cores the size of exec map exceeds 4GB, and all of the operands in the size calculation are 32-bit integers. Tested by: Jim Huang Chen <jim.chen.1827@gmail.com> MFC after: 1 week Sponsored by: AMD (hardware)
* amd64: Remove a prototype for an unimplemented functionMark Johnston2026-07-211-1/+0
| | | | | | Fixes: 6e93f5e4d693 ("amd64: FRED support") Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D58379
* amd64: Fix an off-by-one in the fred_ipi_handlers definitionMark Johnston2026-07-211-1/+1
| | | | | | Fixes: 6e93f5e4d693 ("amd64: FRED support") Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D58378
* exterror: advertise error strings via kern.features.exterr_stringsAlexander Leidinger2026-07-211-0/+4
| | | | | | | | | | | | Allow userland, in particular test cases for EXTERROR conversions, to detect at run time whether extended errors include the descriptive message strings, which depends on the EXTERR_STRINGS kernel option and cannot be probed in any other way. Reviewed by: kib MFC after: 1 week Assisted-by: Claude Code (Fable 5) Differential Revision: https://reviews.freebsd.org/D58321
* vtnet: Accept VIRTIO_NET_F_CTRL_RX_EXTRAFaraz Vahedi2026-07-211-0/+1
| | | | | | | | | | | Although the driver does not issue the extra receive-mode commands accepting the feature is harmless and some devices, notably Apple's Virtualization.framework, offer their control-queue features as a group and refuse FEATURES_OK unless the whole set is acknowledged. Signed-off-by: Faraz Vahedi <kfv@kfv.io> Reviewed by: adrian Pull Request: https://github.com/freebsd/freebsd-src/pull/2322
* vtnet: Implement VIRTIO_NET_F_GUEST_ANNOUNCEFaraz Vahedi2026-07-212-0/+90
| | | | | | | | | | | | | | | | | | | | | | | When the device sets VIRTIO_NET_S_ANNOUNCE in the config status field, for example after a VM migrates to a new host, announce the interface's presence on the network so peers and switches learn the new attachment point, then acknowledge the request with the VIRTIO_NET_CTRL_ANNOUNCE_ACK control command, as per VirtIO v1.3, 5.1.6.5.4. The announcement raises iflladdr_event: the stack sends gratuitous ARPs and unsolicited neighbor advertisements for the interface's addresses, and stacked interfaces such as vlan(4) propagate the event and announce theirs as well. The event handlers may sleep, so the work is deferred from the config change interrupt to a task on taskqueue_thread; that context also allows the acknowledgement to be skipped safely if the interface was stopped in the meantime, in which case the device keeps the bit set and the request is re-delivered with the next config change interrupt. Signed-off-by: Faraz Vahedi <kfv@kfv.io> Reviewed by: adrian Pull Request: https://github.com/freebsd/freebsd-src/pull/2322
* vtnet: Retry feature negotiation without offloadsFaraz Vahedi2026-07-212-2/+30
| | | | | | | | | | | | | | | | | | | | | | | | A device is permitted to reject an otherwise valid subset of its offered features by refusing to accept FEATURES_OK (VirtIO v1.3, 2.2.2). Apple's Virtualization.framework does this in practice; it treats the offered CSUM/TSO offloads as all-or-nothing, while vtnet's default request contains only part of that group because of hw.vtnet.lro_disable that would drop the guest TSO bits, thus negotiation fails and the device does not attach. If FEATURES_OK is rejected, retry the negotiation once with every offload-related feature stripped. Changing the feature set after a failed FEATURES_OK requires re-initialising from device reset (VirtIO v1.3, 3.1.1), so the retry goes through virtio_reinit(). A NIC without offloads is preferable to no NIC at all. Devices that accept the initial feature set are unaffected, while those that also reject the reduced set continue to fail attachment as before. Signed-off-by: Faraz Vahedi <kfv@kfv.io> Reviewed by: adrian Pull Request: https://github.com/freebsd/freebsd-src/pull/2322
* LinuxKPI: 802.11: always lock around (*set_{frag,rts}_threshold)Bjoern A. Zeeb2026-07-212-0/+8
| | | | | | | | | | | | | | We would lock the downcalls during normal operation but not during vap (vif) creation as there was no need for locking. Add the missing locking there as drivers seem to always expect it (by assertion) and cannot distinguish between state. Add the assertions to the downcalls as we need both of them locked and both of them can sleep. PR: 296185 ("rtw89(4) freezes the system with INVARIANTS kernel") Debugged by: Artem Bunichev (temcbun gmail.com) Sponsored by: The FreeBSD Foundation MFC after: 3 days
* hwpmc: Add EXTERROR diagnostics to the hwpmc syscall pathAndre Silva2026-07-212-31/+80
| | | | | | | | | | | | | Annotate validation failures in the PMC syscall handlers (allocate, attach, read/write) with EXTERROR(), so pmc(3) callers see which precondition failed, not a bare errno. Register HWPMC_MOD in exterr_cat.h and the generated filenames.h. Signed-off-by: Andre Silva <andasilv@amd.com> Reviewed by: Ali Mashtizadeh <ali@mashtizadeh.com>, mhorne Sponsored by: AMD Pull Request: https://github.com/freebsd/freebsd-src/pull/2180
* hwpmc: Add EXTERROR diagnostics to the AMD and IBS allocatorsAndre Silva2026-07-213-25/+46
| | | | | | | | | | | | Replace bare EINVAL in AMD/IBS allocation and config-validation with EXTERROR(), so a failed pmc(3) allocation names the check and value. Register HWPMC_AMD in exterr_cat.h and the generated filenames.h. Signed-off-by: Andre Silva <andasilv@amd.com> Reviewed by: Ali Mashtizadeh <ali@mashtizadeh.com>, mhorne Sponsored by: AMD Pull Request: https://github.com/freebsd/freebsd-src/pull/2180
* hid: u2f: stop interrupts on last-closeKyle Evans2026-07-211-3/+0
| | | | | | | | | | | | | | | | | | | | This fixes an issue with the Solo2 (and likely some of the Nitrokey family) where hangs would occur with OpenSSH- it issues a CANCEL prior to closing the device unconditionally, and without draining the read endpoint we end up seeing the response to that CANCEL the next time OpenSSH tries to connect. This throws the entire command/response sequence out of whack. This call used to break Yubikeys in some situations, but the fix that landed in 28d85db46b48 ("xhci: Do not drop and add bits in xhci") seems to have addressed that- presumably we sometimes end up stopping the command and desyncing at the controller level. This probably implies that we need a SYNCWRITE HID quirk, but that requires a little more work in usbhid_sync_xfer() and this doesn't seem to cause any problems in normal usage. Reviewed by: aokblast, wulf Differential Revision: https://reviews.freebsd.org/D58199
* uvideo: fix use-after-free in mmap buffer lifetime managementBaptiste Daroussin2026-07-211-14/+162
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The uvideo driver freed the mmap buffer (contigmalloc'd) in several paths (VIDIOC_STREAMOFF, last close, detach) without coordinating with the lifetime of existing user-space mmap mappings. This could lead to use-after-free when user-space continued to access the mapped memory after the backing pages had been freed. Fix this by switching from the simple d_mmap callback to d_mmap_single with custom cdev_pager_ops, and by attaching the contig buffer to a single shared vm_object created at REQBUFS time: - uvideo_reqbufs() allocates a uvideo_mmap_state (independent of the softc) and a shared vm_object via cdev_pager_allocate() that spans the whole buffer; the softc holds one reference to it. - uvideo_cdev_mmap_single() simply hands out additional references to that shared object; the requested offset selects which buffer is mapped. The VM system tracks mapping lifetime through the object reference count, so no per-mapping bookkeeping is needed. - uvideo_pg_ctor/uvideo_pg_dtor validate the mapping and free the contig buffer together with the state when the last reference (softc's own or a user mapping) is dropped. - uvideo_pg_fault installs a fictitious page for the backing physical address, following the canonical device-pager pattern: update the passed-in page in place when it is already fictitious, otherwise allocate a fake page and vm_page_replace() the busy placeholder, so that dev_pager_dealloc() does not deadlock. - uvideo_vs_free_frame() drops the softc's reference instead of contigfree()'ing directly; if mappings still exist the buffer stays alive until the last uvideo_pg_dtor(). - VIDIOC_STREAMOFF no longer frees the buffer (per V4L2 spec). - Last close always releases the buffer (deferred if mappings exist). - The mmap_state outlives the softc, so the pager dtor can safely free the buffer even after device detach. Reported by: 章鱼哥 (@aipyapp) (www.aipyaipy.com) Reported by: Chris Jarrett-Davies of the OpenAI Codex Security Team
* tcp_hostcache: explicitly typecast atomic_load_int to (int) for comparisonRichard Scheffenegger2026-07-211-1/+1
| | | | | | | Sponsored by: NetApp, Inc. MFC after: 1 week Reviewed By: tuexen, #transport, markj Differential Revision: https://reviews.freebsd.org/D58360
* nvme: Explicitly cast caddr_t valuesDag-Erling Smørgrav2026-07-211-1/+1
| | | | | | | | | Sponsored by: Klara, Inc. Sponsored by: NetApp, Inc. MFC after: 1 week Fixes: 6d0001d44490 ("nvme: add support for DIOCGIDENT") Reviewed by: bnovkov, imp Differential Revision: https://reviews.freebsd.org/D58357
* kern/sys_ptrace: do not skip P2_PTRACEREQ wait for PT_CLEARSTEP/PT_GET_CHILDRENKonstantin Belousov2026-07-211-17/+16
| | | | | | | | Reported and reviewed by: markj Fixes: d3b7bbee9275 ("ptrace(2): add PT_GET_CHILDREN") Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D58364
* sched_4bsd: Allocate runqueues only for present CPUsMinsoo Choo2026-07-211-27/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4BSD has been allocating an array of MAXCPU runqueues, runq_pcpu[], instead of one runqueue per actually present CPU. On amd64, MAXCPU is 1024 and 'struct runq' is 4128 bytes, causing runq_pcpu[] to take more than 4 MiB of memory. On the vast majority of current systems, which have at most 32 cores with SMT, this is a waste of memory. Besides providing per-CPU runqueues, runq_pcpu[] has also been used to determine the CPU ID of a given thread's associated runqueue through pointer arithmetic. Since per-CPU structures are only allocated for present CPUs, in order to save space, move the runqueues to per-CPU fields and, for each thread ('struct ts_sched'), replace its runqueue pointer by the CPU ID of the runqueue it is in (new 'ts_rqcpu' field). Set the thread's CPU ID to the special NOCPU value when it is running on the global runqueue. Drop the SKE_RUNQ_PCPU() macro as it is now simply equivalent to 'ts_rqcpu != NOCPU'. Introduce the TS_RUNQ_PTR() macro to get a pointer to the thread's runqueue, which must be passed to runq_add() and runq_remove(). [olce: Massaged the commit message. Fixed an inverted KASSERT(). Tested with source builds.] Reviewed by: olce Tested by: olce MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D58000
* sched_4bsd: Rename the global runqueueMinsoo Choo2026-07-211-16/+16
| | | | | | | | | | | | | | | | | | | | | | | | | In an upcoming change whose purpose is to stop having 4BSD always allocate MAXCPU runqueues, wasting space on most machines, 'struct td_sched' will store the CPU ID to which a thread is bound/pinned instead of a pointer to the corresponding runqueue. As a consequence, existing functions manipulating a thread's runqueue will need to point to the inferred runqueue through a local variable. The name 'runq' is the ideal one for these local variables, but before this change it designated the global runqueue, also causing unnecessary ambiguity. Thus, rename the global runqueue to the more explicit 'runq_global'. Arguably, this should have been performed as part of commit e17c57b14ba9 ("- Implement cpu pinning and binding. (...)"). No functional change (intended). [olce: Massaged the commit message. Tested with source builds.] Suggested by: olce Reviewed by: olce Tested by: olce MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D58065
* sched_4bsd: Remove obsolete SMP scaling for ticks per priority levelOlivier Certner2026-07-211-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | The INVERSE_ESTCPU_WEIGHT scaling had been introduced by commit b698380f33ef ("Quick fix for scaling of statclock ticks in the SMP case. ...") to leave more discrimination room for multiple CPUs possibly adding their ticks to the same 'struct ksegrp' (but also slightly changing how CPU hogs are penalized). Then, commit 8460a577a4b4 ("Make KSE a kernel option, ...") introduced the current thread-based code, where tick accounting is only done on the current thread, which renders this trick obsolete on !KSE. Finally, when KSE was removed, the trick became generally obsolete. The trick is actually even harmful because it changes the intended behavior of priorizing more the CPUs that use the less ticks (and so, impairs boosting "interactive" processes). Remove it now. Clamping of 'ts_estcpu' and its relation to the load-average-based decay may be re-examined later. Fixes: 8460a577a4b4 ("Make KSE a kernel option, ...") MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D57827
* sched_4bsd: Fix conflating priority of differently-niced CPU-bound threadsOlivier Certner2026-07-211-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We introduced (PRI_MAX_TIMESHARE - PRI_MIN_TIMESHARE) as part of ESTCPULIM() in commit eebc148f25c3 ("sched_4bsd: ESTCPULIM(): Allow any value in the timeshare range") in order to use more than a fixed number (40) of all the available priority levels in the timeshare range (136 before the 256-queue runqueue work, 224 now) to take into account the number of ticks a thread has run ('ts_estcpu'). In the computation of a new thread's priority (resetpriority()), in addition to the "ticks running" contribution, the final priority also includes a "nice" value contribution. The final value is clamped into the [PRI_MIN_TIMESHARE; PRI_MAX_TRIMESHARE] range. Problem is that the new "ticks running" contribution now can lead to a computed priority value that exceeds PRI_MAX_TRIMESHARE, and is thus finally clamped to PRI_MAX_TIMESHARE, which becomes an alias for all out-of-bound values. In particular, this can conflate CPU-hungry threads. With at least two of them competing on the same CPU, with an increase of 'ts_estcpu' of ~64 per second (stathz being 127) and the minimal decay of 4/5 (load average 2 or more), both threads will easily reach the current clamping of 224 (+ PRI_MIN_TIMESHARE), and be considered indifferently by the scheduler. Fix this problem by ensuring that the maximum contribution of 'ts_estcpu' (via ESTCPULIM()) cannot exceed the timeshare range of priorities when the nice contribution is added to it, so the nice contribution continues to have an effect on CPU-bound threads. Introduction of the nice term in ESTCPULIM() (then NICE_WEIGHT * PRIO_MAX) has been done in commit bdf423572ee3 ("Scheduler fixes equivalent to the ones logged in the following NetBSD commit...") and does not appear to have made any real sense even then. Fixes: bdf423572ee3 ("Scheduler fixes equivalent to the ones logged in the following NetBSD commit...") Fixes: eebc148f25c3 ("sched_4bsd: ESTCPULIM(): Allow any value in the timeshare range") MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D57826
* firewire: replace magic numbers with named constantsAbdelkader Boudih2026-07-2012-58/+112
| | | | | | | No functional change. Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D58311
* firewire: remove dead code across the subsystemAbdelkader Boudih2026-07-209-428/+3
| | | | | Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D58310
* firewire: force root change when root node is not cycle master capableAbdelkader Boudih2026-07-201-3/+4
| | | | | | | | | When a FireWire bus resets, all devices negotiate who is the new boss. when we detect the root node can't be cycle master, we send a PHY config packet that forces a reelection. Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D58309
* firewire: drain pending xfers after callout stop in detachAbdelkader Boudih2026-07-201-1/+3
| | | | | | | Removes a TODO that predates the existing drain call. Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D58308
* firewire: add warn-only CRC validation for CSR ROM directoriesAbdelkader Boudih2026-07-205-1/+32
| | | | | | | | | | | | Implemented crom_crc_valid() helper to validate IEEE 1394 config ROM CRC-16 checksums. Skipped root header CRC validation since csrhdr.crc_len cover the entire ROM body which is not fully read at header parse time. Per-directory CRC checks below catch corruption where it needed. Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D58307
* net80211: update drivers to allocate sequence numbers in the raw pathAdrian Chadd2026-07-205-2/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | A bunch of drivers weren't properly converted. I mistakenly put a call to ieee80211_output_seqno_assign() wherever the crypto header was added, which isn't exactly correct. There are plenty of drivers which don't share enough of their raw and normal transmit path code for that to hold true. So after some manual review, it looks like I've captured the places (outside of iwn(4) which I committed earlier) where I missed ieee80211_output_seqno_assign() calls. * For bwi(4) and bwn(4) I refactored it out into a place that is common enough and happens in the same lock hold window, so it's serialised. * For the rest, it's just plain missing from the raw path. Locally tested: * ural(4) * ral(4) * bwi(4) Differential Revision: https://reviews.freebsd.org/D58098
* lookup: do not return vp_crossmp as dvp for mount over the reg fileKonstantin Belousov2026-07-202-5/+38
| | | | | | | | | Return the covered vnode instead. Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D58191
generated by cgit v1.3 (git 2.53.0) at 2026-09-01 19:02:08 +0000