tests/ip_mroute: Use a router address as the IPv4 RP
pimd 3.0.0 and later refuse an RP in 127.0.0.0/8.
Reported by: markj
Approved by: markj
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/92
Don't some prune empty dirs created by BSD.tests.dist
Before this change, directories needed when MK_DTRACE_TESTS != no and
MK_ZFS_TESTS != no but not MK_TESTS != no, were being created via
`BSD.tests.dist` as part of the standard build/install process with the
top-level `hierarchy` target. This behavior resulted in `make check-old`
flagging a lot of issues after 30c20ca26e105c, even after `make
delete-old` was run and the directories were removed.
Remove the logic which pruned these empty directories; this "fixes" the
issue with `make check-old`, et al and allows a proper technical solution to
`OptionalObsoleteFiles.inc` to be implemented by pkgbase in an unimpeded
manner without introducing additional complexity.
See the review for more details.
PR: 299650
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D60928
libpmc: Map AMD Family 1Ah models 00h-0Fh to amdzen5
178d0b5b8da7 adapted the Zen 5 pattern matching from Linux perf.
However, Linux prints CPU models with a single digit when under 0xF
(allowing |[[:xdigit:]] to match 0h-Fh), whereas hwpmc/libpmc formats
model numbers with two leading hex digits (00h-0Fh).
Fix the pattern to explicitly cover two-digit hex models in the 00h-0Fh
range, and add a test case verifying table selection across Zen 5 and Zen 6
cpuid strings.
Reviewed by: Ali Mashtizadeh <ali at mashtizadeh.com>
Signed-off-by: Osvaldo Janeri Filho <ojanerif at amd.com>
Fixes: 178d0b5b8da7 ("libpmc: Import AMD Zen 6 PMU events.")
Sponsored by: Advanced Micro Devices, Inc.
Differential Revision: https://reviews.freebsd.org/D60625
hwpmc: use the PerfMonV2 DF encoding on Family 19h
Family 19h processors with PerfMonV2 use the Family 1Ah DF encoding.
Selecting it by family alone drops the upper unit mask bits, and most
DF events count zero.
Reviewed by: Ali Mashtizadeh <ali at mashtizadeh.com>
Sponsored by: AMD
MFC after: 1 week
Signed-off-by: Osvaldo Janeri Filho <ojanerif at amd.com>
Differential Revision: https://reviews.freebsd.org/D60769
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(4): stop overwalking past _start on amd64 user callchains
pmc_save_user_callchain() emits the pc it just loaded before checking
whether fp is the ABI's zero frame-chain terminator. At the bottom of
a well-formed chain under _start, fp comes back 0 as expected, but the
paired pc is stale rtld data left on the stack -- a legal userspace VA
that still passes PMC_IN_USERSPACE(), so it gets emitted as a bogus
extra frame. This shows up in flame graphs as a spurious hex-valued
root frame below _start.
Check fp == 0 alongside the existing checks before emitting, matching
how arm/arm64/powerpc already load the next fp before their check.
Measured via 1kHz hwpmc sampling on an OCA: stacks with any unresolved
hex frame drop from 23.9% to 1.3%, and stacks with hex at the root drop
from 5.5% to 0.3%.
Reviewed by: mhorne, Ali Mashtizadeh <ali at mashtizadeh.com>, gallatin
MFC after: 3 days
[4 lines not shown]
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)
bhyve: restore the BARs at the addresses the guest gave them
A restore set the addresses in the BARs and the command register to
those of the snapshot, but left the regions registered where
pci_emul_alloc_bar() had put them when bhyve started. That is only
right for a guest that kept bhyve's addresses. The UEFI firmware moves
64-bit BARs above 4 GB, and after a restore every access to such a BAR
went nowhere:
Emulating access to non-existent address to 0x800001014
Before the devices are restored, unregister the regions of all of them;
when a device is restored, register its regions at the restored
addresses, if the restored command register enables them. All devices
go first because a restored BAR may be where another device's BAR is
before the restore.
Signed-off-by: Wanpeng Qian <wanpengqian at gmail.com>
Sponsored by: keelos.dev
[4 lines not shown]
uart: Set the bus space tag before parsing hw.uart.console
uart_cpu_getdev() lets hw.uart.console override the FDT, but
uart_getenv() maps an "mm:" address with uart_bus_space_mem, which is
only assigned after the FDT probe. On riscv and arm it is still NULL
at that point, so bus_space_map() faults before there is a console.
On riscv this happens on any EFI boot where the firmware provides an
SPCR table, since the loader turns it into hw.uart.console.
Initialize uart_bus_space_mem to fdtbus_bs_tag, as uart_cpu_arm64.c
does with &memmap_bus (See also 0624eddcffefe).
PR: 299089
Reviewed by: mhorne
MFC after: 1 week
Signed-off-by: Rick Richard <rick at sloservers.com>
LinuxKPI: Add drm support to dev_is_pci() function
drmn driver is attached to PCI bus via intermediate vgapci driver.
Check for it presence in device tree branch too to handle drm-kmod
cases.
MFC after: 2 month
Reviewed by: emaste (LGTM)
Differential Revision: https://reviews.freebsd.org/D60138
vt_vga: repost only a vgapci(4) video device
When vt(4) falls back to vt_vga, vga_init() passes vd_video_dev to
vga_pci_repost(), which expects a vgapci(4) device. The framebuffer
driver that set it need not provide one: drm-kmod's linux_fb passes the
parent of the DRM parent device, which is vgapci for LinuxKPI PCI
drivers but the PCI bus for virtio-gpu, whose DRM parent is the virtio
PCI transport. On x86, vga_pci_repost() then calls pci_get_class() on
the bus, which fails the accessor's KASSERT under INVARIANTS; without
INVARIANTS the class reads as 0 and the repost is skipped. Repost only
a vgapci device.
Signed-off-by: Denis Borovikov <denis.borovikov at gmail.com>
Reviewed by: wulf
Differential Revision: https://reviews.freebsd.org/D60880
bnxt: avoid unintialized use of media_type in bnxt_add_media_types()
When 5e6e4f752833 landed, it inadvertently allowed unsupported / unknown
phys with a valid link_info->sig_mode to use media_type uninitialized.
Fix this by returning from those cases that do not assign a media_type
so as to avoid using it uninitialized.
Reported by: imp (forwarding an llm's post-commit review of previous
changes to this file)
Fixes: 5e6e4f752833
Reviewed by: imp, kbowling, sumit.saxena_broadcom.com
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D61164
iflib: prefer simple_tx over mp_ring
In preparation for removing mp_ring, enable simple_tx by default.
Users encountering bugs are still able to set the tunable:
net.iflib.prefer_mpring="1"
at boot, but are encouraged to report any regressions so they
can be fixed.
My plan is to remove mp_ring assuming no major bugs are found in
simple_tx after a month or two.
Reviewed by: kbowling, netchild, rcm
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D61166
ixgbe: Guard E610 Link Default Override access
Reading Link Default Override uses the E610 Admin Command Interface,
whose mutex is initialized only on E610. Calling it on other adapters
can hang attach, as observed on X520.
Skip the read on non-E610 devices, leaving the cached policy invalid so
that the existing link-state guard also skips force-link commands.
Reviewed by: kgalazka
Fixes: 7868958f5c79 ("ix(4): Support Total Port Shutdown on E610")
MFC after: 1 week
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D61144
bhyve: check paddr_guest2host return in _vq_record
_vq_record() stored the result of paddr_guest2host() without checking for
NULL. A guest descriptor with an invalid address causes a NULL dereference
in every virtio driver. Return early on failure; the caller sees zero
descriptors and discards the chain.
The indirect path already performs this check (line 357).
Reviewed by: bnovkov
Differential Revision: https://reviews.freebsd.org/D60870
MFC after: 1 week
cap_enter(2): stricter checks
- single-thread the process
Make cap_enter() a serialization point, ensuring that no threads are
executing with old credentials cached after the syscall returned.
- disallow entering capability mode if the file descriptor table or pwd
are shared. They are shared after rfork(2), and allowing it lets another
process grant additional privileges to the process in capability mode.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D60963
kern: do not allow unprivileged chroot when pwd is shared
Unprivileged chroot(2), fchroot(2), chaltroot(2), and fchaltroot(2)
rely on PROC_NO_NEW_PRIVS to make set-ID images harmless under the
new root. But the pwddesc can be shared by rfork(2) without RFFDG
with a process that has not enabled PROC_NO_NEW_PRIVS, and the
change of the root affects that process as well. It can then
execute a set-ID image whose ELF interpreter is resolved under the
root controlled by the caller.
Refuse the unprivileged operations when the pwddesc is shared.
Processes that start sharing it later are created by the caller and
inherit PROC_NO_NEW_PRIVS.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D60963
pwddesc: add sharecount
The pd_refcount field counts both sharing processes and the transient
pdhold() references taken by sysctls and mountcheckdirs(), so it
cannot answer "is this pwddesc shared". As a result pdunshare() made
needless copies while the pwddesc was held, and a copy made while
mountcheckdirs() held it lost the cwd/root update.
Add pd_sharecount, counting only processes using the pwddesc, and use
it for the sharing decision. Existing pd_refcount still manages the
lifetime.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D60963
Makefile.inc1: Fix bare $ characters
The '$' characters inside awk commands need to be $$ when appearing
inside a Makefile. Without this, we generate empty src and src-sys
packages.
Reported by: Stefan Grundmann
Fixes: a8be89928930 ("build: Support got")
MFC after: 1 day
(cherry picked from commit 6a99232c75f6460b03a95019e2625828a158d457)
sdiob: copy vendor/device IDs from card common CIS
Copy both the vendor and device IDs from the card common CIS if they are
absent in a function.
These are optional according to the spec. [1]
[1] Part E1 SDIO Simplified Specification §16.6
MFC after: 3 days
Reviewed by: kibab, imp, adrian
Differential Revision: https://reviews.freebsd.org/D60988
auditd: Support logging directly to syslog
Every tenth call to auditwarnlog(), check that the audit_warn(5) script
exists and is executable by us. If it is, execute it as previously;
otherwise, fall back to calling syslog(3) directly.
Additionally, if we choose to use the script and fail, also log the
original message to syslogd, not just the fact that we failed to log.
We could record the result of trying to execute the script, but that
would require pausing while it runs (or at least until the execve(2)
call has completed).
Retesting every tenth call is a little clunky but avoids having to
restart or signal auditd(8) to force it to notice a change in
availability, or adding a command-line option and / or modifying the
audit_control(5) syntax to let the user express a preference.
MFC after: 1 week
[4 lines not shown]
audit_warn: Avoid pointless fork and path search
While here, document what the script actually does, not what it once did
on a project branch somewhere that was never merged.
MFC after: 1 week
Sponsored by: Klara, Inc.
Sponsored by: Qualys, Inc.
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D60171
arm64/vmm: Disable fine grained trapping of range-based TLBI instructions
vmm passes the FEAT_TLBIRANGE field of ID_AA64ISAR0_EL1 to the guest, but also
enables fine-grained traps in the range-based TLBI instructions. This didn't
cause a problem until commit 5549785
("arm64 pmap: use range-based TLBI instructions"); following this commit, the VM
will exit with VM_EXITCODE_REG_EMUL during boot if the host supports FEAT_FGT and
FEAT_TLBIRANGE.
This commit disables fine-grained trapping of these instructions.
Reviewed by: andrew
Sponsored by: Arm Ltd
Pull Request: https://reviews.freebsd.org/D60196
