libkern.h: remove HAVE_INLINE_* macros
The final consumer of this was OpenZFS, fixed in ffaea0831973 (thanks
mav@). That change has been present in all active OpenZFS release
branches for at least 6 months. These can finally be retired.
Reviewed by: mav
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55201
(cherry picked from commit 76f14217f6051df414e435c3388d3f4bb388cc22)
jh7110_gpio: remove unneeded cleanup
Any failure within bus_alloc_resources() will call bus_release_resources();
thus the call is redundant here.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 2af2ec524957754ff356daea5fa7ee4990c1c3ea)
jh7110_gpio: driver enhancements
Fix reporting of state and capabilities by the gpioctl command.
Support selection of pull-up and pull-down resistors.
Support second gpio device (AON - always on power domain) to allow
attaching gpioled device to visionfive2 status LED or querying boot
selection switches.
Reviewed by: mhorne
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D58693
(cherry picked from commit 3d20f8a022435e8ed37e2c0ce8f66d4c1203ec1c)
release/riscv: tweak GENERICSD partition placement
Increase EFI partition size to begin rootfs at 64mb. I believe this was
my original intention. I have a microSD card with 8mb block size which
emits an advisory in verbose dmesg about the misaligned partition.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 49749f21284d817b5431255106c8c2da3afa9965)
hwpmc: fix false callchain assertion on the PMC_UR ring
pmc_capture_user_callchain() asserts that TDP_CALLCHAIN is set on the
current thread, but PMC_UR samples never set that flag -- only PMC_HR
and PMC_SR do. That makes the assertion always fail for PMC_UR,
panicking INVARIANTS kernels as soon as pmcstat -U is used.
Skip the assertion for PMC_UR. No functional change on kernels built
without INVARIANTS.
Signed-off-by: Andre Silva <andasilv at amd.com>
Reviewed by: mhorne
MFC after: 1 week
Sponsored by: AMD
Differential Revision: https://reviews.freebsd.org/D58572
(cherry picked from commit af3929c5152b47278c0b6ea66efbb782b9637495)
hwpmc: fix false runcount assertion in user callchain capture
pmc_capture_user_callchain() checks a PMC's runcount before walking
the user stack, but reads it without holding the spinlock that
protects it. hardclock() can run on the same CPU during the capture
and drop the runcount to zero in between, tripping the assertion and
panicking INVARIANTS kernels under load.
Move the check inside the existing spinlock, right where the code
already confirms the sample is still valid. No functional change on
kernels built without INVARIANTS.
Signed-off-by: Andre Silva <andasilv at amd.com>
Reviewed by: mhorne
MFC after: 1 week
Sponsored by: AMD
Differential Revision: https://reviews.freebsd.org/D58571
(cherry picked from commit 66118c3f1011d7852bce8b659899179a83781897)
pmc: Add support for AMD UMC counters
This change adds support for AMD's UMC performance counters. It is a
bit more complicated than existing counters because the enable bit has
moved. This supports Zen 4 through most Zen 6 chips as UMC counters are
per-node, where a node does not necessarily translate to a NUMA domain.
A few follow up changes to PMC will address this limitation.
Reviewed by: mhorne
Sponsored by: Netflix
Pull Request: https://github.com/freebsd/freebsd-src/pull/2368
nvme: limit namespace character-device I/O size
The namespace character device does not initialize si_iosize_max, so
physio falls back to DFLTPHYS and can produce a bio larger than the
qpair payload DMA tag on a controller whose maximum transfer size is
below 64KB. Such a bio fails DMA mapping and is never submitted.
Approved by: ngie (co-mentor)
MFC after: 1 week
Reviewed by: ngie, imp
Differential Revision: https://reviews.freebsd.org/D59152
nvme: complete requests when payload DMA mapping fails
bus_dmamap_load_mem() reports most mapping failures, including EFBIG,
only through its callback and then returns zero. nvme_payload_map()
logged the error without telling the submission path, so the tracker
stayed on the outstanding list with no command submitted and no
timeout armed, stalling all later I/O on the queue behind it.
Approved by: ngie (co-mentor)
MFC after: 1 week
Reviewed by: ngie, imp
Differential Revision: https://reviews.freebsd.org/D59151
sys/arm: Fix DTrace trap hook
Move the dtrace_trap hook at the start of the abort handler to exit
early when a trap is handled by DTrace.
Fix the type argument to be the actual fault type instead of the value
of the FAR. The latter will need to be added to the trapframe, until
then DTrace will report unmapped addresses as the null address.
Correct the comment of the PUSHFRAMEINSVC assembler macro to reflect
that coming from SVC32 mode is expected for DTrace traps.
PR: 298064
MFC after: 1 month
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D59279
vm_page_free.9: Remove references to vm_page_try_to_free()
That function was removed in commit 98549e2dc6fb0.
PR: 288081
Fixes: 98549e2dc6fb ("Centralize the logic in vfs_vmio_unwire() and sendfile_free_page().")
dtrace/arm: Fix and de-pessimize dtrace_copy
Use an unprivileged load to access user memory from dtrace_copy, which
is running in SVC mode.
Abort the loop if the load is trapped, as it is useless, hence
wasteful, to keep faulting on successive addresses. I believe that
this de-pessimization should also be done on aarch64 and riscv.
PR: 298064
MFC after: 1 month
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D59280
dtrace/arm: Really trap translation faults
Fix the constant case label to properly handle translation faults
caused by DTrace probes. Alignment errors are not expected to be
generated, so stop handling them.
While at it, correct an amd64-specific comment and add a comment
regarding the missing faulting address which could be addressed by a
later improvement.
PR: 298064
MFC after: 1 month
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D59281
iflib: update rs_pending based on descriptors consumed by isc_txd_encap
The new watchdog code triggers spurious watchdog resets on
NICs doing KTLS offload. Fix this by using the actual segments
consumed by the NIC driver's isc_txd_encap.
The issue is that rs_pending is updated using an estimate of
the descriptors that will be used for the current packet,
based on what bus_dma produced. However, NICs which support
ktls offload may do extra DMAs (and consume extra
descriptors) to derive crypto state when re-transmitting
TLS segments. This is the reason for allowing drivers to control
ift_pad. When this happens, the estimated rs_pending may undercount.
This may also happen if NIC drivers consume extra descriptors for
other reasons. (eg, hw errata handling on e1000)
Reviewed by: kbowling
Differential Revision: https://reviews.freebsd.org/D59321
Sponsored-by: Netflix
hastd: Fix crash on empty message
A HAST message can be empty, in which case ebuf_add_tail() does nothing
and ebuf_data() returns NULL because the size of the ebuf is zero, but
hast_proto_recv_hdr() asserts that the return value is not NULL,
resulting in an immediate crash if hastctl or hastd receive an empty
message. This is trivially reproducable by running `hastctl status` or
`hastctl role init` (as the rc script does prior to stopping hastd).
To avoid this, don't try to grow the ebuf or receive additional data
if the header size is zero.
PR: 298085
MFC after: 3 days
Reviewed by: kevans, gjb
Differential Revision: https://reviews.freebsd.org/D59306
(cherry picked from commit 8646d65b45339642d4aab1de35a2bc79fc45f09e)
various: Fix nlist invocations
Fix nlist(3) consumers that either expected our toolchain to prepend an
underscore to symbol names or expected nlist(3) to ignore the mismatch,
as it did until we overhauled it back in May.
While here, also fix cases where the last element in the list had an
empty string instead of NULL as sentinel.
MFC after: 3 days
Fixes: 4617a6cb82a6 ("nlist: Handle multiple symbol tables")
Reviewed by: kib, jhb
Differential Revision: https://reviews.freebsd.org/D59254
(cherry picked from commit cdfc673811aca2c6690f37bde9ef4896ea2e1d6b)
various: Fix nlist invocations
Fix nlist(3) consumers that either expected our toolchain to prepend an
underscore to symbol names or expected nlist(3) to ignore the mismatch,
as it did until we overhauled it back in May.
While here, also fix cases where the last element in the list had an
empty string instead of NULL as sentinel.
MFC after: 3 days
Fixes: 4617a6cb82a6 ("nlist: Handle multiple symbol tables")
Reviewed by: kib, jhb
Differential Revision: https://reviews.freebsd.org/D59254
(cherry picked from commit cdfc673811aca2c6690f37bde9ef4896ea2e1d6b)
hastd: Fix crash on empty message
A HAST message can be empty, in which case ebuf_add_tail() does nothing
and ebuf_data() returns NULL because the size of the ebuf is zero, but
hast_proto_recv_hdr() asserts that the return value is not NULL,
resulting in an immediate crash if hastctl or hastd receive an empty
message. This is trivially reproducable by running `hastctl status` or
`hastctl role init` (as the rc script does prior to stopping hastd).
To avoid this, don't try to grow the ebuf or receive additional data
if the header size is zero.
PR: 298085
MFC after: 3 days
Reviewed by: kevans, gjb
Differential Revision: https://reviews.freebsd.org/D59306
(cherry picked from commit 8646d65b45339642d4aab1de35a2bc79fc45f09e)
hastd: Fix crash on empty message
A HAST message can be empty, in which case ebuf_add_tail() does nothing
and ebuf_data() returns NULL because the size of the ebuf is zero, but
hast_proto_recv_hdr() asserts that the return value is not NULL,
resulting in an immediate crash if hastctl or hastd receive an empty
message. This is trivially reproducable by running `hastctl status` or
`hastctl role init` (as the rc script does prior to stopping hastd).
To avoid this, don't try to grow the ebuf or receive additional data
if the header size is zero.
PR: 298085
MFC after: 3 days
Reviewed by: kevans, gjb
Differential Revision: https://reviews.freebsd.org/D59306
hastd: Clean up the ebuf code
Rename the members of struct ebuf to match their function, replace
bcopy() with memcpy(), add comments explaining what each function does.
Reviewed by: kevans, emaste
Differential Revision: https://reviews.freebsd.org/D59310
fsck_msdosfs: add a test for reconnecting on volumes larger than 4 GiB
Build a 4.5 GiB FAT32 image whose LOST.DIR cluster sits exactly 4 GiB above
the single cluster of a PAYLOAD.BIN, so that truncating the offset of the
former to 32 bits yields the offset of the latter, then inject a lost cluster
chain and let fsck_msdosfs(8) reconnect it.
The test asserts both halves of the bug fixed in the previous commit: that
PAYLOAD.BIN's cluster is unchanged, and that a second pass no longer reports
the chain as lost, which it only stops doing once the directory entry reaches
the real LOST.DIR.
newfs_msdos(8) -C only calls ftruncate(2) and nothing outside the reserved
area, the FATs and a handful of clusters is ever written, so the image stays
sparse and costs about 2 MiB on disk.
The geometry is read back out of the BPB rather than assumed, so
newfs_msdos(8) stays free to lay the file system out differently; the test
fails with a clear message if the volume ever becomes too small to hold a
[3 lines not shown]
fsck_msdosfs: fix 32-bit overflow computing the LOST.DIR offset
reconnect() computed the byte offset of the LOST.DIR cluster in 32-bit
arithmetic and widened the result only on assignment:
lfoff = (lfcl - CLUST_FIRST) * boot->ClusterSize
+ boot->FirstCluster * boot->bpbBytesPerSec;
cl_t is u_int32_t and ClusterSize is u_int, so both products wrap modulo
2**32. Once LOST.DIR's cluster lies past the 4 GiB mark, lfoff aliases
the offset exactly 4 GiB below it, which on such a volume is ordinary
file data.
That offset is used for both the read and the write: reconnect() reads a
cluster of file data, scans it in 32-byte steps for a leading SLOT_EMPTY
or SLOT_DELETED byte, which arbitrary data readily provides, stores the
new directory entry in that slot, and writes the cluster back to the
same wrong place. Thirty-two bytes of an unrelated file are silently
replaced by a directory entry, and since that entry never reaches the
[14 lines not shown]
fsck_msdosfs: add tests for the 32-bit boot block field decoding
Exercise each of the 32-bit BIOS Parameter Block and FSInfo fields that
readboot() decodes, using values whose most significant byte has its high
bit set. Each case checks two things: that fsck_msdosfs(8) reports the
full unsigned 32-bit value back on stdout, and that nothing writes a
sanitizer runtime error to stderr.
The second check is what catches a byte-at-a-time decode. Shifting such
a byte left by 24 is undefined, but every compiler we use wraps it into
the same bit pattern, so the decoded value alone cannot tell a correct
decode from an overflowing one. In a WITH_UBSAN build bsd.sanitizer.mk
compiles with -fsanitize=undefined and -fsanitize-recover=undefined, so
the shift is reported on stderr and execution continues, which the test
can then assert on. Against the byte-at-a-time decode these cases fail
in a WITH_UBSAN build and pass without it.
Note that the stderr check also fails on unrelated undefined behavior
that these images reach anywhere in fsck_msdosfs(8), which is intended.
[2 lines not shown]
fsck_msdosfs: avoid signed integer overflow in readboot()
readboot() decoded the 32-bit little-endian BIOS Parameter Block and
FSInfo fields by shifting the individual bytes of a u_char array into
place. The u_char operands are promoted to signed int, so shifting a
most significant byte of 0x80 or greater left by 24 overflows int, which
is undefined behavior. Use le32dec() from <sys/endian.h> instead, which
is both well defined and easier to read.
No functional change intended.
MFC after: 1 week
Pull Request: https://github.com/freebsd/freebsd-src/pull/2350
