syslogd: Fix ereregex property filters and add test
This change fixes Bug 293879, where ereregex filters in syslogd
did not handle alternation correctly.
The issue appears to come from mixing up two different kinds of
flags: syslogd's internal serialized filter flags in
usr.sbin/syslogd/syslogd.h, and the regex compilation flags from
include/regex.h. ereregex was storing REG_EXTENDED in cmp_flags,
even though cmp_flags is meant to carry syslogd's own FILT_FLAG_*
values for configuration serialization and reconstruction.
REG_EXTENDED has the same bit value as FILT_FLAG_EXCLUDE, so the
filter could be reconstructed with the wrong semantics.
The fix stores FILT_FLAG_EXTENDED instead, allowing syslogd to
correctly REG_EXTENDED when compiling the regex.
A test was also added for both ereregex and !ereregex filters.
[7 lines not shown]
usbdevs: Add USB device IDs for Nuand bladeRF SDR
Add vendor and product IDs for bladeRF family of USB software defined radios manufactured by Nuand LLC.
Reviewed by: imp, adrian
Differential Revision: https://reviews.freebsd.org/D54733
nfs_nfsdsocket.c: All Copy and Clone across file systems
For some server file system types, such as ZFS, a Copy/Clone
operation can be done across file systems of the same file
system type.
As such, this patch allows the Copy/Clone to be attempted
when the file handles are for files on different file systems.
This fixes a problem for exported ZFS file systems when a
copy_files on file_range(2) between file systems in the same
NFSv4 mount is attempted.
PR: 294010
MFC after: 2 weeks
HBSD: Build framework updates
In preparing the next quarterly build (2026q2), I discovered that
HardenedBSD 15-STABLE is lagging behind with regards to building the
installer images. This commit brings us more up-to-date and fixes the
build.
This is a direct commit to 15-STABLE.
Signed-off-by: Shawn Webb <shawn.webb at hardenedbsd.org>
dup(2): document the handling of filedescriptor flags
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Differential revision: https://reviews.freebsd.org/D56121
diff3: set O_CLOEXEC on pipes
This avoid leaking pipe fd in children and simplifies the code
MFC After: 1 week
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D56120
Hyper-V: Detect Extended Destination ID support
Hyper-V advertises support for the Extended Destination ID standard via
bit 2 of the value returned in the EAX register when the hypervisor
stack properties are queried via CPUID.
This is based on a commit to the Linux kernel, as there does not seem
to be any other documentation of this feature.
Reviewed by: Souradeep Chakrabarti
MFC after: 3 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D55432
Bhyve: Detect Extended Destination ID support
Bhyve advertises support for the Extended Destination ID standard via
bit 0 (aka CPUID_BHYVE_FEAT_EXT_DEST_ID) of the value returned in the
EAX register when Bhyve features are queried via CPUID.
MFC after: 3 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D55431
vmm: Move defines from x86.c to x86/bhyve.h
The values CPUID_BHYVE_FEATURES and CPUID_BHYVE_FEAT_EXT_DEST_ID are
useful for guests, not just hosts; so they belong in a header file in
sys/x86/include rather than simply in the .c file implementing the
bhyve host side.
The original addition of these defines took place without adding a
copyright statement, but since I'm moving them into a new file I've
added the original author's standard copyright (Amazon).
MFC after: 3 weeks
Fixes: 313a68ea20b4 ("bhyve: Add CPUID_BHYVE_FEATURES leaf")
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D55430
Xen: Detect Extended Destination ID support
Xen advertises support for the Extended Destination ID standard via
bit 5 (aka XEN_HVM_CPUID_EXT_DEST_ID) of the value returned in the
EAX register when Xen features are queried via CPUID.
MFC after: 3 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D55429
KVM: Detect Extended Destination ID support
KVM advertises support for the Extended Destination ID standard via
bit 15 of the value returned in the EAX register when KVM features
are queried via CPUID.
Tested on: EC2 r8i.96xlarge
MFC after: 3 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D55427
io_apic: Support APIC Extended Destination IDs
If APIC Extended Destination ID support is enabled, use it in APIC RTEs
by allowing APIC IDs up to 2^15 - 1 and encoding the high bits into
Intel "reserved" bits per the standard.
Reviewed by: kib
MFC after: 3 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D55889
msi: Support APIC Extended Destination IDs
If APIC Extended Destination ID support is enabled, use it in MSIs by
allowing APIC IDs up to 2^15 - 1 and encoding the high bits into
Intel "reserved" bits per the standard.
Tested on: EC2 r8i.96xlarge
MFC after: 3 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D55426
x86: Add stub for Extended Destination ID support
Without an IOMMU, the APIC standard only allows 8 bits of Destination
ID for MSI messages, limiting us to 256 CPUs. While IOMMUs can allow
for more than 256 CPUs to be supported, they are not necessarily
desirable in virtualized environments.
The Extended Destination ID standard authored by David Woodhouse uses
7 "Reserved" bits for the high bits of a 15-bit Extended Destination
ID in order to address this: http://david.woodhou.se/ExtDestId.pdf
Add a loader tunable machdep.apic_ext_dest_id to control the use of
this feature; the default value (-1) means "autodetect" while 0 and
1 mean disabled and enabled respectively.
Code to detect host support in Xen, Hyper-V, KVM, and Bhyve will come
in future commits, as will the code to use this setting in msi_map and
ioapic_program_intpin.
[4 lines not shown]
io_apic: Don't route to APIC ID > 255
I/O APIC Redirection Table Entries use 8 bits to encode the Destination
ID. Attempting to route an IRQ to a higher APIC ID would result in it
being silently routed to the value reduced modulo 256, causing a panic
if the IRQ fired since the receiving CPU would not expect that IRQ.
Instead, print a warning and mark the interrupt as invalid, resulting
in it being forcibly masked.
Reviewed by: kib
Tested on: EC2 r8i.96xlarge
MFC after: 3 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D55857
x86: Add struct ioapic_intsrc.io_valid
As of this commit, io_valid is always set to 1; but a future commit
will set it to 0, at which point IOART_INTMSET will be set to forcibly
disable interrupt sources regardless of whether they are requested to
be "masked".
Reviewed by: kib
MFC after: 3 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D56006
clapic_handle_intr: KASSERT isrc != NULL
If an interrupt arrives at a CPU which isn't expecting that particular
vector, intr_lookup_source will return an isrc of NULL and we'll panic
when intr_execute_handlers increments *isrc->is_count.
Place a KASSERT a few nanoseconds earlier in order to leave some more
breadcrumbs for the next person to trip over this behaviour.
Tested on: EC2 r8i.96xlarge
MFC after: 3 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D55851
i386/amd64/NOTES: Add some missing devices
The following devices to x86: ocs_fc aq vge tws
And this to amd64: ufshci
These are in GENERIC, but not NOTES.
Sponsored by: Netflix
vmgenc: fix typo in MODULE_DEPEND declaration
The random_harvestq dependency was registered under the misspelled
name "vemgenc" instead of "vmgenc", causing the dependency to not
be associated with the correct module.
Signed-off-by: Christos Longros <chris.longros at gmail.com>
Reviewed by: cem, imp
Differential Revision: https://reviews.freebsd.org/D56012
