xhci: Enlarge total transfer number
We enlarge the total number of queued transfer. Also, to make controller
always busy. We enqueue the xfer as much as possible to the ring in
multiple enter code.
Differential Revision: https://reviews.freebsd.org/D61246
xhci: Map stream id to occupied slot
In xhci_check_transfer, we tried to iterate through STREAM * NUM_SLOTS
and find the correct stream. However, stream is rear nowadaya both on
FreeBSD and Linux. In which means that such STREAM * NUM_SLOTS array is
sparse.
As a result, we use a bit map to map stream id to slot. For a
xhci_mask[stream_id], it contains the slot_id bitmap over which slot has
been occupied.
Differential Revision: https://reviews.freebsd.org/D61247
Fix double free when cloning a block with a pending free
dmu_read_l0_bps() captures the source block pointers for a clone
without consulting dnode_block_freed(). A block whose free is recorded
but not yet synced still has a valid on-disk pointer, so the clone
registers a BRT reference to a block about to be returned to the
allocator, and it is freed twice. On a debug build this trips the
metaslab double-free verifier; on a release build the space map is
silently corrupted.
Check for a pending free and return EAGAIN, as dbuf_read_hole() already
does for buffered reads. zfs_clone_range() waits a TXG and retries, by
which point the block reads as a hole.
Two cases need more than the plain check. A hole has nothing to free,
so guard with !BP_IS_HOLE(bp), otherwise a hole inside a pending free
range fails a FICLONE that master cloned. When the head dirty record
already overrode the BP, only frees after the override count against
it, so use dnode_block_freed_after(); dbuf_free_range() leaves the
[19 lines not shown]
dbuf: restore BP_IS_HOLE() recheck after dnode_block_freed()
Commit 79cf54582 ("Fix reads for blocks freed after being cloned")
reworked the level-0 check in dbuf_read_hole() and dropped the
BP_IS_HOLE() recheck that followed dnode_block_freed(), together with
the comment explaining it. That recheck was not about overrides: it
closes a race with dnode_sync().
dnode_sync_free_ranges() drops dn_mtx, clears the bps through
dnode_sync_free_range_impl() -> free_blocks(), then retakes dn_mtx and
removes the range from dn_free_ranges. For blkptrs held in the dnode
(dn_nlevels == 1), free_blocks() writes the bp without the parent's
db_rwlock, so holding that lock in dbuf_read() does not serialize
against it. A reader that saw a non-hole bp, then waited on dn_mtx in
dnode_block_freed() until the range was removed, gets "not freed" while
the bp it is about to copy is already a hole (with HOLE_BIRTH, lsize
and birth preserved). dbuf_read_impl() then hands that hole to
arc_read(): no child I/O is issued, checksum verification fails with
EINVAL, and without ZIO_FLAG_CANFAIL the pool is suspended.
[26 lines not shown]
Fix direct reads of blocks pending free
Direct reads only check the on-disk block pointer for holes, so they
can read stale data after a block has been freed but before the free
has synced. Share buffered read hole detection with direct reads to
honor pending frees as well.
Keep cached data ahead of hole detection and preserve the transaction
ordering of block clone and direct write overrides. Retain the block
pointer recheck after dnode_block_freed() for concurrent syncing.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Wale Zhang <wale.zhang.ftd at gmail.com>
Closes #19633
Approved by: re (cperciva)
Approved by: kevans (mentor)
(cherry picked from commit 924b8c89c04e324649855b05986f686b58ca4cb9)
(cherry picked from commit afc7fc2abe807780e6f9cba96ab73105ebd2a07f)
amd64/vmm: Don't advertise AMD PerfMonV2 or performance counters
vmm does not handle CPUID leaf 0x80000022, so a FreeBSD guest on a
Family 19h or later host panics on "kldload hwpmc", which trusts the
PerfMonV2 bit and writes AMD_PMC_GLOBAL_CTL.
Approved by: re (cperciva)
Tested by: Osvaldo Janeri Filho <ojanerif at amd.com>
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Reviewed by: markj, kib
Differential Revision: https://reviews.freebsd.org/D61141
(cherry picked from commit 8fb539b081dbfe3e93e607a5d4d36184c53c8aaf)
(cherry picked from commit ade540f274d52366b46da2898b2c264b4e89883a)
UPDATING: note login-name validation in pw(8)/pwd_mkdb(8)
An existing master.passwd with a login name containing a now-disallowed
charater will make pwd_mkdb(8) fail until the name is fixed, which blocks
passwd(1), chpass(1) and pw(8). Warn users to audit their accounts
befroe updating.
Reviewed by: bcr
Differential Revision: https://reviews.freebsd.org/D61507
sched_ule: Fix rare deadlock on stealing a migrated lock-blocked thread
Thread stealing ultimately happens in tdq_move() which, while holding
the locks of the source and destination runqueues, has to wait for the
stolen thread to be lock-unblocked. If it is indeed lock-blocked, the
corresponding sched_switch_migrate() needs to re-acquire the lock of the
runqueue of the CPU it is running on before being able to lock-unblock
it. This amounts to adding a "hidden" and variable additional
lock-ordering dependency between the 'struct tdq' locks held by
tdq_move() and that of an arbitray third 'struct tdq', possibly
violating the ordering established by tdq_lock_pair(). In that case,
other steals occurring in parallel and involving the same queues can
deadlock the scheduler.
Fix that by having sched_switch_migrate() hold its current CPU's
runqueue's lock in addition to the remote CPU's before the migrated
thread can appear on the remote runqueue, so that it does not have to
re-acquire the former, removing the "hidden" lock-ordering dependency.
[127 lines not shown]
sched_ule: tdq_move(): INVARIANTS: Remove a superfluous assertion
That the lock of the stolen thread is the same as the source runqueue is
already checked by sched_rem().
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
sched_ule: sched_rem(): Use THREAD_LOCKPTR_ASSERT() instead of MPASS()
This gives a better message.
While here, add some empty lines to make INVARIANTS-only statements
stand out for better readability.
No functional change.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
proc.h: Order thread_lock*() functions more logically
Also matches the implementation order in 'kern_mutex.c'.
No functional change.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
sched_ule: tdq_add(): INVARIANTS: Add check, fix name in assertion strings
Change the assertion on the to-add thread's lock so that it also fails
if the thread's lock is not that of the 'tdq' (the checks that it is
lock-unblocked and locked remain).
It is tempting to add another check that the thread's 'ts_cpu'
corresponds to the passed runqueue (in other words, that it has been set
correctly), but that requires to add a call to thread_lock_block_wait()
which should not be present in non-debug code, and that may prevent some
races from happening on INVARIANTS, so I gave up on it.
Fix the function name in assertion strings, as sched_add() is not the
only (direct or indirect) caller of tdq_add().
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
sched_ule: Document fields of 'struct runq_steal_pred_data'
While here, re-order them to have inputs before outputs.
No functional change.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
geom: Check file flags before handling control request
Pass fflag down to g_ctl_req() and:
* Refuse all requests unless fflag has the FREAD bit set
* Refuse all but getxml unless fflag also has the FWRITE bit set
This should allow us to restore read access to /dev/geom.ctl for group
operator; they will then be able to run `gpart list` or `gpart backup`
but not commands that actually modify the table.
For backward compatibility, we set the FWRITE bit if it is not already
set and the calling thread has the PRIV_GEOM privilege, which is
automatically granted to a jailed or unjailed superuser. This should
cover the case of older binaries (which open /dev/geom.ctl read-only)
running as root on a newer kernel. Since we intend to merge this to
stable/15, the compatibility code is conditional on COMPAT_FREEBSD14.
[4 lines not shown]
libgeom: Open the control device read-write
Try to open the control device read-write first, and fall back to
read-only if that fails and the error is EACCES. This prepares us for a
future in which GEOM requires write access to execute verbs that modify
the configuration.
MFC after: 1 week
Event: EuroBSDCon 2026 DevSummit
Reviewed by: imp, markj, emaste
Differential Revision: https://reviews.freebsd.org/D59592
acpi_pci_link: Ignore tunables with negative values
IRQ values are unsigned and negative values do not make sense. The
invalid IRQ value (255) is already ignored, so ignoring other invalid
values is consistent with that behavior.
Reported by: cperciva
acpi_pci_link: Handle IRQ values > 255
Some systems use a stub PCI link device for hardwired interrupts
instead of static _PRT entries. These link devices can use an IRQ >
255. The current driver was designed to handle PCI link devices on
x86 used for legacy INTx IRQs which were < 255. These changes handle
larger IRQ values while making a few tradeoffs.
- Expand most IRQ fields from 8 bits to 32-bits. The BIOS IRQ
(read from the PCIR_INTLINE config register which is an 8-bit register)
remains 8 bits.
- Add a wrapper API for managing interrupt weights and avoid tracking
weights for IRQs > 255 and instead report a constant weight of 0 for
IRQs > 255.
PR: 300476
Reported by: Aviv Bakal <avivb at amazon.com>
Tested by: cperciva
tests: Add test for vn_io_fault1 bug
This bug was fixed in b487aca48535, but I did not have a regression
test ready for it at the time.
The test allocates a large buffer, faults part of it in and leaves the
rest unmapped, then tries to read a 3 GiB file into it. If the bug is
present, the read succeeds, but the return value exceeds the requested
amount by exactly one page less than the amount that was prefaulted.
PR: 298159
MFC after: 1 week
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D61475
(cherry picked from commit ba02bbbe86aeca0c95c8e7d12c1be357ebb3ddeb)
tests: Improve vn_io_fault1 test
[21 lines not shown]
tests: Add test for vn_io_fault1 bug
This bug was fixed in b487aca48535, but I did not have a regression
test ready for it at the time.
The test allocates a large buffer, faults part of it in and leaves the
rest unmapped, then tries to read a 3 GiB file into it. If the bug is
present, the read succeeds, but the return value exceeds the requested
amount by exactly one page less than the amount that was prefaulted.
PR: 298159
MFC after: 1 week
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D61475
(cherry picked from commit ba02bbbe86aeca0c95c8e7d12c1be357ebb3ddeb)
tests: Improve vn_io_fault1 test
[21 lines not shown]
stdio: Fix positional %F conversion
When a format uses positional arguments, __find_arguments() walks it
first to learn the type of every argument, and lists the floating
point conversions as A a E e f G g. F is missing, so a double that
is only referred to through %F never gets a type, its slot in the
argument table stays unset, and the conversion reads whatever is
there:
printf("[%1$F]\n", -INFINITY); [0.000000]
printf("[%1$F]\n", 1.5); [0.000000]
printf("[%F]\n", 1.5); [1.500000]
With a width taken from another argument, "%1$*2$F", vsnprintf(3)
returned lengths like 2103024 for a ten character result; abseil's
str_format test allocates that much and was killed for it on
FreeBSD. The same format with %1$f, or with any other conversion of
the same argument, works because those give it a type.
[7 lines not shown]
netmap: Handle TX buffers larger than MCLBYTES
The generic netmap TX pool always allocates standard clusters
(zone_clust), even though the buffer size may be larger.
INVARIANTS kernels panic in nm_os_get_mbuf() on first transmit through a
non-native NIC (e.g. re or epair) using netmap with jumbo frames
configured. Release kernels silently truncate frames in
nm_os_generic_xmit_frame().
Implement cluster zone selection based on the requested size. Catch
oversized requests in nm_os_catch_tx() and return EINVAL. Add a KASSERT
before the truncation fallback in xmit. Make nm_os_get_mbuf() take a
uint32_t size, matching the type of the value passed to it.
Tested using epair, pkt-gen, and tcpdump on release (15.1) and
INVARIANTS (main) kernels at buffer sizes 2048/4096/9216/16384.
Reviewed by: vmaffione, kevans, markj
[2 lines not shown]
