eecp holds the extended capability offset. If that offset is larger
than 0xff, storing it in uint8_t truncates it, which can make the
early EHCI/XHCI capability walk read the wrong location and loop during
boot.
Seen on AMD device 1022:151e, where HCCPARAMS1 = 0x0118ffc5 and the
first xHCI extended capability offset is 0x460. Widen eecp to uint32_t
in xhci_early_takeover(), matching xhci_pci_take_controller().
Signed-off-by: Gisle Nes <gisle@gisle.net>
Reviewed by: zlei, aokblast
MFC after: 3 days
Pull Request: https://github.com/freebsd/freebsd-src/pull/2127
Closes: https://github.com/freebsd/freebsd-src/pull/2127
This is only used by rc.subr and belongs in rc, not runtime.
Fixes: fa6d67cd16 ("BSD.root.dist: Add package tag for all directories")
MFC after: 3 days
Reviewed by: ivy
Differential Revision: https://reviews.freebsd.org/D56900
When fsck_msdosfs runs with FAT32 cache mode (used for large
filesystems that cannot be mmap'd), a detected FAT header correction
was written into the in-memory buffer but the corresponding cache
entry (fat32_cache_allentries[0]) was never marked dirty. As a
result, fat_flush_fat32_cache_entry() skipped it, the corrected
bytes were never written to disk, and copyfat() propagated the
uncorrected on-disk data to all backup FAT copies. Every subsequent
fsck run would repeat the same "FAT starts with odd byte sequence /
FIXED" cycle indefinitely.
Fix by marking fat32_cache_allentries[0].dirty = true after applying
the in-memory correction, ensuring the chunk is flushed before
copyfat() runs.
Obtained from: https://android-review.googlesource.com/c/platform/external/fsck_msdos/+/4047981
MFC after: 3 days
Thread Safety Analysis: Fix pointer handling of variables with deprecated attributes (#148974)
de10e44b6fe7 ("Thread Safety Analysis: Support warning on
passing/returning pointers to guarded variables") added checks for
passing pointer to guarded variables. While new features do not
necessarily need to support the deprecated attributes (`guarded_var`,
and `pt_guarded_var`), we need to ensure that such features do not cause
the compiler to crash.
As such, code such as this:
struct {
int v __attribute__((guarded_var));
} p;
int *g() {
return &p.v; // handleNoMutexHeld() with POK_ReturnPointer
}
Would crash in debug builds with the assertion in handleNoMutexHeld()
triggering. The assertion is meant to capture the fact that this helper
should only be used for warnings on variables (which the deprecated
attributes only applied to).
To fix, the function handleNoMutexHeld() should handle all POK cases
that apply to variables explicitly, and produce a best-effort warning.
We refrain from introducing new warnings to avoid unnecessary code bloat
for deprecated features.
Fixes: https://github.com/llvm/llvm-project/issues/140330
This fixes an assertion while building the net/openvswitch port:
"Assertion failed: ((POK == POK_VarAccess || POK == POK_VarDereference)
&& "Only works for variables"), function handleNoMutexHeld, file
/usr/src/contrib/llvm-project/clang/lib/Sema/AnalysisBasedWarnings.cpp,
line 2120.'
Reported by: cy
PR: 295101, 292067
MFC after: 1 month
If the user runs "make update-packages" without bumping BRANCH, then it
isn't possible to copy packages from the old location to the new one
(because the two locations are the same). So just skip that step.
Sponsored by: ConnectWise
PR: 295085
MFC after: 1 week
Reviewed by: ivy, emaste
Differential Revision: https://reviews.freebsd.org/D56872
Previously the cr_pid field would be incorrectly copied to userland, due
to a size mismatch between the structure as defined in 32-bit vs 64-bit
builds. Fix it by converting the structure before copying it to
userland.
PR: 294833
Sponsored by: ConnectWise
MFC after: 1 week
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D56675
Test what happens when we ask for the rdev of a non-device.
MFC after: 1 week
Sponsored by: Klara, Inc.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D56838
Update smartpqi(4) to document the dev.smartpqi.<unit>.debug_level
sysctl for runtime debug level changes, and note that device
add/remove and controller event messages always appear in dmesg
regardless of the debug_level setting.
PR: 294161
Reviewed by: imp
Approved by: imp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D56832
The smartpqi driver did not log device add/remove or controller events
to syslog, and hw.smartpqi.debug_level could only be set at boot via
loader.conf with no runtime sysctl interface.
Add a read-write sysctl at dev.smartpqi.N.debug_level for runtime
debug level changes. Add device_printf calls for device addition,
removal, and controller events (hotplug, hardware, physical/logical
device, AIO state/config changes) so state changes always appear in
dmesg. Add DBG_DISC logging for discovery state transitions. Fix
spelling errors in strings and comments across the driver.
Bump driver version to 14.4691.1.2000 / 15.2.1.2000.
PR: 294161
Reviewed by: imp
Approved by: imp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D56832
Enabling ZSTD_TRACE leaves behind undefined weak symbols, which causes a
problem for gcc builds. The bfd linker emits an obscure error about
overlapping FDEs. We don't need ZSTD_TRACE for libsa, so just disable
it.
Also disable BMI2 instruction optimizations. The addition of the
optional BMI2 code paths caused the boot loader binaries to grow larger
(28 KiB for clang, 32 KiB for gcc). The boot loader binaries are size
constrained, and this pushed the gcc-generated lua_loader.bin over the
500000 byte limit, and the clang one to within 4k of the limit.
Fixes: 8a62a2a565 ("zfs: merge openzfs/zfs@f8e5af53e")
Reviewed by: delphij, imp, mm
Differential Revision: https://reviews.freebsd.org/D56866
The FreeBSD network stack, for better or worse, does not impose any
requirements on interface names. As such it's valid for an interface
name to start with a number (or indeed, be something like '⭐').
Allow this in pfctl, and add a test case for the specific case of
interface names starting with a number.
Note that we don't support UTF-8 names fully, so those may still fail.
PR: 295064
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
When dumping states optionally (at '-vv') also show the rule which
created the state. This can be helpful if the ruleset changed and we
want to know what rule created the state.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Only call buf_flush() if there are some dirty buffers belonging to the
vnode we are allocating the buffer for. Otherwise the bd dirty queue
scan cannot find anything and it makes no sense to spend CPU doing it.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
When a file is created via p9fs with restrictive permissions (like 000),
the 9P TCREATE request successfully creates and natively opens the file,
returning an open, writable file descriptor. Previously, p9fs would
attempt a subsequent TOPEN. That TOPEN would fail with EACCES due to the
restrictive mode, leaving a 0-byte file and causing operations like 'mv'
to abort.
We now preserve the writable descriptor returned by TCREATE so that the
subsequent VOP_OPEN can use it directly, avoiding the failing TOPEN.
Additionally, p9fs_compatible_mode now appropriately isolates the base
access intent when matching fids, preventing extended flags from
breaking the match.
A test case for this behavior has been submitted to pjdfstest:
https://github.com/pjd/pjdfstest/pull/87
Resolves: https://github.com/CTSRD-CHERI/cheribsd/issues/2617
Reviewed by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D56494
This is needed for various pjdfstest tests which fail with syntax errors
if pathconf _PC_NAME_MAX/_PC_PATH_MAX return -1. For NAME_MAX we can use
the 9P2000.L Tstatfs call to get namelen from the host. While this could
theoretically be different for nested filesystems in the shared mount it
is a much better guess than just returning 255.
There does not seem to be a way to get the host PATH_MAX, so we just
return the conservative kernel default.
Found while fixing https://github.com/CTSRD-CHERI/cheribsd/issues/2617.
Reviewed by: markj, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D56493
Previously, the UMA zones required for 9P requests (p9fs_buf_zone,
p9fs_req_zone, etc.) were initialized and destroyed in the
virtio_p9fs transport module. This caused issues when unloading
the core p9fs module.
This change moves p9_init_zones() and p9_destroy_zones() into
p9fs_init() and p9fs_uninit() inside p9fs_vfsops.c so that they
are correctly bound to the VFS filesystem module lifecycle via
vfs_modevent, aligning p9fs with standard FreeBSD VFS semantics.
Found while fixing https://github.com/CTSRD-CHERI/cheribsd/issues/2617.
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D56492
The virtio_p9fs module event handler can be invoked multiple times.
Previously, this caused p9_init_zones() and p9_register_trans() to be
executed multiple times, leaking UMA zones and corrupting the transport
list. During module unload, p9_destroy_zones() was also called multiple
times on the same zone pointers, triggering a duplicate free kernel panic
in uma_zdestroy().
This patch introduces a static reference counter in vt9p_modevent() to
ensure the zones and transports are only initialized and destroyed exactly
once, aligning with the approach used by other virtio drivers like vtnet.
Reviewed by: kib, markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D56497
This ensures this header can be included without an explicit or implicit
sys/types.h include first. This causes issues building SPEC2017 which
includes sys/rtprio.h and then we get an error due to missing u_char
definition.
Reviewed by: emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D52041
Avoid dependency on INET (IPv4) by using PF_LOCAL,
allowing media check to work on systems without INET support.
PR: 295045
Reviewed by: kevans
MFC after: 1 week
The jail(8) command must not leave parsed configuration files open
since the file descriptors will be leaked to child processes
including the untrusted exec.start or exec.stop hooks.
While fopen() doesn't provide direct access to O_CLOEXEC, it does
provide access to FD_CLOEXEC via "e" in the mode string which
provides the desired defense in depth against leaking file descriptors
into exec.* hooks since those always execve() into a shell.
Jail configuration is potentially sensitive and some hooks execute from
within the jail context, leaving some opening for the jail to exfiltrate
information about the host environment.
(Commit message wordsmithed by kevans)
PR: 295052
Reviewed by: kevans
MFC after: 3 days
Ensure the script used is invalid when parsed by libyaml which
highlight the issue revealed in PR295062
while at here validate the mode of the file is properly changed
PR: 295062
MFC After: 1 day
Blocking allocation is safe in all of the current callers of kobj_init
(most of them do a M_WAITOK malloc of the structure passed as the
first argument to kobj_init just before calling it). kobj_init
doesn't return an error code but instead panics if the nested malloc
in kobj_class_compile1 fails, so using M_WAITOK here is more robust.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D56625
Reorder the TLS RX teardown sequence so the TIR is destroyed before
the DEK. DESTROY_TIR for a TLS-enabled TIR issues a TRA RX fence
that drains all in-flight packets from the crypto pipeline. If the
DEK is destroyed first, packets still in flight hit a TPT encryption
error (vendor syndrome 0x55) because the key they reference is
already gone.
Reviewed by: kib
Sponsored by: Nvidia networking
MFC after: 1 week
This fixes a regression introduced in cae280931c which prevents
user_data as a shell script to be used
PR: 295062
Reported by: Ross McKelvie <ross@exitzero.uk>
MFC After: 1 day
The __maybe_unused attribute should be used for variables which may or
may not be used, such as when their only use is in an assertion. This
attribute is functionally identical to __unused, suppressing compiler
warnings for particular variable if it remains unused.
Reviewed by: Minsoo Choo <minsoo@minsoo.io>, imp
Differential Revision: https://reviews.freebsd.org/D56517
Jilles Tjoelker