epair: add VLAN_HWTAGGING
Add capability VLAN_HWTAGGING to the epair interface and enable it by
default.
When sending a packet over a VLAN interface that uses an epair
interface, the flag M_VLANTAG and the ether_vtag (which contains the
VLAN ID and/or PCP) are set in the mbuf to inform the hardware that
the VLAN header has to be added. The sending epair end does not need
to actually add a VLAN header. It can just pass the mbuf with this
setting to the other epair end, which receives the packet. The
receiving epair end can just pass the mbuf with this setting to the
upper layer. Due to this setting, the upper layer believes that there
was a VLAN header that has been removed by the interface.
If the packet later leaves the host, the outgoing physical interface
can add the VLAN header in hardware if it supports VLAN_HWTAGGING.
If not, the implementation of Ethernet or bridge adds the VLAN header
in software.
Reviewed by: zlei, tuexen
[2 lines not shown]
dpaa2: add support for several interface counters
Add support for IFCOUNTER_IPACKETS, IFCOUNTER_OPACKETS,
IFCOUNTER_OBYTES, IFCOUNTER_OMCASTS, IFCOUNTER_OERRORS, and
IFCOUNTER_OQDROPS.
This allows tools like systat to report the incoming and outgoing
bandwidth.
Reviewed by: dsl, Timo Völker
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D54893
powerpc: explicitly cast the timebase printfs
This is causing compilation issues on powerpc:powerpc GENERIC.
(cherry picked from commit 03e4cc9fdeb2a6445f13cd41b471927a0f722fff)
powerpc: explicitly cast the timebase printfs
This is causing compilation issues on powerpc:powerpc GENERIC.
(cherry picked from commit 03e4cc9fdeb2a6445f13cd41b471927a0f722fff)
powerpc: add a best-effort SMP time base sync for G5's that need it
There's no timebase freeze platform routine registered on my dual 2.3GHz
G5 PPC970FX Apple PowerMac.
For platforms without an explicit timebase freeze/unfreeze, we'll have to
make do with what we have - which for now is an explicit hand-crafted
spinlock/rendezvous method.
* For existing platforms, they'll still continue to clock freeze /
rendezvous; albeit with some stronger atomic bits now (from jhibbits@.)
* Instead of the fallback being "no timesync", implement a
best-effort one which does a similar rendezvous barrier between
BSP and APs, but instead of freeze/unfreeze the first instruction
after the CPUs all register they're ready is to set the timebase.
This has resulted in many reboots of my Powermac G5 dual-socket device
correctly starting and running in SMP mode.
[4 lines not shown]
powerpc: fix release image building for Apple partitions
awk changed somewhere between 14 and 15 and it stopped accepting
a hexadecimal number as its input - it will always return 0.
This results in a very badly written apple boot block.
So just remove it; do the math in shell.
PR: kern/292341
Differential Revision: https://reviews.freebsd.org/D54639
Reviewed by: imp
MFC after: 1 week
(cherry picked from commit 7afa03963c448a14b1735a10eaf84941b0b74862)
powerpc: put the isync inside the TD_LOCK() checking loop
Fix a narrow window where the lock is unlocked but the checking CPU
hasn't flushed things appropriately.
Inside this window the CPU inside cpu_switch() will loop forever thinking
the destination thread is still blocked/locked even though it is not.
This manifests as the system hanging after starting all APs.
I've seen this reliably trigger in qemu-system-ppc64 running power9 pseries
guests; the more CPUs the more likely it triggers at boot.
PR: kern/292167
Differential Revision: https://reviews.freebsd.org/D54478
Reviewed by: jhibbits
MFC after: 1 week
Relnotes: yes
(cherry picked from commit 8df2e542146801fd01675e56724eaa567d04c209)
powerpc: add a best-effort SMP time base sync for G5's that need it
There's no timebase freeze platform routine registered on my dual 2.3GHz
G5 PPC970FX Apple PowerMac.
For platforms without an explicit timebase freeze/unfreeze, we'll have to
make do with what we have - which for now is an explicit hand-crafted
spinlock/rendezvous method.
* For existing platforms, they'll still continue to clock freeze /
rendezvous; albeit with some stronger atomic bits now (from jhibbits@.)
* Instead of the fallback being "no timesync", implement a
best-effort one which does a similar rendezvous barrier between
BSP and APs, but instead of freeze/unfreeze the first instruction
after the CPUs all register they're ready is to set the timebase.
This has resulted in many reboots of my Powermac G5 dual-socket device
correctly starting and running in SMP mode.
[4 lines not shown]
nanobsd: embedded: Stub out experimental functions
Stub out both experimental functions introduced in ecc039be7fdd when
doing embedded builds.
Fixes: ecc039be7fdd ("nanobsd: Add a NO_ROOT build option")
MFC after: 3 days
libc: Don't use uninitialised string for getnetbyaddr[_r](0) DNS lookup
If net is all-zero, the loop to extract all leading non-zero octets will
iterate zero times and leave nn with the value 4, which the following
switch statement to initialise qbuf does not handle. As a result,
_dns_getnetbyaddr will look up the PTR record for this uninitialised
string, which will leak the pre-existing contents of that stack memory
to the DNS resolver and, if remote and not otherwise protected, network.
Note that _dns_getnetbyaddr is only used if nsswitch.conf is configured
to enable the "dns" source for the "networks" database, which is not the
default configuration in FreeBSD.
For glibc this same bug, in code also derived from BIND's, was issued
CVE-2026-0915. This commit adopts the same behaviour as glibc's fix,
which is to regard a net of 0 as being for 0.0.0.0. Apparently NetBSD
will return NS_UNAVAIL instead, which may or may not make more sense,
but in general glibc compatibility tends to cause less friction when
there's not a good reason to avoid it.
[7 lines not shown]
Merge commit faa5141b9be4 from file git (by Christos Zoulas):
PR/656: harry.sintonen: Fix bug in byte swapping that was caused by the change to make flags uint16_t and cont_level uint8_t.
This fixes using a magic.mgc built with a different endianness than
file(1) itself, e.g. when building powerpc64 on amd64.
PR: 292079
Fixes: ae316d1d1cff ("MFV: file 5.46.")
MFC after: 3 days
(cherry picked from commit 39047538cf5d8f26112f7b08b3c56967f70f7f94)
libc: Don't use uninitialised string for getnetbyaddr[_r](0) DNS lookup
If net is all-zero, the loop to extract all leading non-zero octets will
iterate zero times and leave nn with the value 4, which the following
switch statement to initialise qbuf does not handle. As a result,
_dns_getnetbyaddr will look up the PTR record for this uninitialised
string, which will leak the pre-existing contents of that stack memory
to the DNS resolver and, if remote and not otherwise protected, network.
Note that _dns_getnetbyaddr is only used if nsswitch.conf is configured
to enable the "dns" source for the "networks" database, which is not the
default configuration in FreeBSD.
For glibc this same bug, in code also derived from BIND's, was issued
CVE-2026-0915. This commit adopts the same behaviour as glibc's fix,
which is to regard a net of 0 as being for 0.0.0.0. Apparently NetBSD
will return NS_UNAVAIL instead, which may or may not make more sense,
but in general glibc compatibility tends to cause less friction when
there's not a good reason to avoid it.
[7 lines not shown]
libc: Don't use uninitialised string for getnetbyaddr[_r](0) DNS lookup
If net is all-zero, the loop to extract all leading non-zero octets will
iterate zero times and leave nn with the value 4, which the following
switch statement to initialise qbuf does not handle. As a result,
_dns_getnetbyaddr will look up the PTR record for this uninitialised
string, which will leak the pre-existing contents of that stack memory
to the DNS resolver and, if remote and not otherwise protected, network.
Note that _dns_getnetbyaddr is only used if nsswitch.conf is configured
to enable the "dns" source for the "networks" database, which is not the
default configuration in FreeBSD.
For glibc this same bug, in code also derived from BIND's, was issued
CVE-2026-0915. This commit adopts the same behaviour as glibc's fix,
which is to regard a net of 0 as being for 0.0.0.0. Apparently NetBSD
will return NS_UNAVAIL instead, which may or may not make more sense,
but in general glibc compatibility tends to cause less friction when
there's not a good reason to avoid it.
[7 lines not shown]
Merge commit faa5141b9be4 from file git (by Christos Zoulas):
PR/656: harry.sintonen: Fix bug in byte swapping that was caused by the change to make flags uint16_t and cont_level uint8_t.
This fixes using a magic.mgc built with a different endianness than
file(1) itself, e.g. when building powerpc64 on amd64.
PR: 292079
Fixes: ae316d1d1cff ("MFV: file 5.46.")
MFC after: 3 days
(cherry picked from commit 39047538cf5d8f26112f7b08b3c56967f70f7f94)
Revert "src.opts.mk: Enable LLDB by default globally"
This breaks the riscv64 build; clearly the version we have in-tree is
not new enough to work. That or our build system needs tweaking. Either
way, we're not ready for this, and enabling it without testing was
misguided.
This reverts commit c59a47dc6c016dff74466cecb160459980a5d782.
firmware: Fix inverted FIRMWARE_GET_NOWARN logic
The try_binary_file() function has inverted logic for the
FIRMWARE_GET_NOWARN flag. When the flag is set (meaning "don't warn"),
the code sets warn=true and makes noise anyway.
Invert the assignment to warn to correctly suppress warnings when
FIRMWARE_GET_NOWARN is set.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D54955
SCHED_4BSD: maybe_resched() cannot schedule ast() for curthread
maybe_resched() needs to schedule TDA_SCHED for curthread, but this
requires taking curthread lock while owning some other thread lock.
To avoid introducing the order:
- Use a scheduler-private TDP flag.
- Register an unconditional TDA_SCHED_PRIV for 4BSD.
When an AST needs to be scheduled, i.e. the current thread must do
context switch in the return to userspace path, set the flag.
Then the ast handler calls ast_scheduler(), which gives the same
effect as scheduling TDA_AST.
The overhead is a single function call on each userspace return, for
4BSD case.
Reported and tested by: pho (previous version)
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D54945
lindebugfs: check that name is set as otherwise pfs_alloc_node_flags() panics
I have hit the case multiple times that some LinuxKPI field may not be
set during driver bringup and lindebugfs would cause a panic.
The backtrace goes like:
strlen() at strlen+0x54
pfs_create_dir() at pfs_create_dir+0x41
debugfs_create_dir() at debugfs_create_dir+0xa1
...
While the problem is clearly in LinuxKPI or the driver, we likely
should at least add an assert to pfs_create_dir() if name is NULL
like we have for pfs_add_node() but for lindebugfs at least make
this a graceful error and continue without creating the dir instead
of panicing.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
[2 lines not shown]
sched_shim: restore kern.ccpu sysctl
It is apparently should be considered part of the ABI, and is used by
the base top(1). But do not declare the ccpu variable in headers, it is
needed only by 4bsd. So put the variable definition into sched_shim.c to
make the kernel buildable without SCHED_4BSD.
Reviewed by: olce
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D54831
kern/sched: move duplicate preemption stat vars into sched_shim.c
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D54831
x86/cpu_machdep.c: unconditionally fence
For !SCHED_ULE, even if the fence is not needed, it is harmless.
Reviewed by: olce
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D54831
x86/local_apic.c: remove direct SCHED_ULE use
Move the code to decide on the timer accounting into the scheduler hook.
Since there were no inclusion of opt_sched.h, it is probably done
unconditionally anyway.
Reviewed by: olce
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D54831
