The camera control IDs in videoio.h changed numeric values; ports
consuming V4L2 camera controls need to be rebuilt.
Reviewed by: thierry
Differential Revision: https://reviews.freebsd.org/D59460
Renumbered the camera class to match the reference ABI and added the
constants ported applications expect:
Reviewed by: thierry
Differential Revision: https://reviews.freebsd.org/D59459
The initializer just needs working malloc(9) and two constants that
are set at hammer_time().
Fixes: 648fa3558c
Reviewed by: avg, markj
Differential Revision: https://reviews.freebsd.org/D58714
The entropy will be collected in intr_event_schedule_thread() for event
handlers that are marked as entropy sources. The quality of entropy
provided by SWI wasn't great anyway.
Reviewed by: cem, ngie
Differential Revision: https://reviews.freebsd.org/D58829
Both kern_renameat() and kern_dup() had arguments named `new`. Rename
their arguments to match their respecitve manual pages.
Sponsored by: Klara, Inc.
Sponsored by: NetApp, Inc.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D59386
The proto-libnv implementation embedded in hastd pads names and values
out to the nearest multiple of eight bytes, but leaves the padding
uninitialized, leaking up to 14 bytes of recycled heap per pair in a
message.
While here, switch from bcopy() to memcpy().
MFC after: 3 days
Reviewed by: kevans, emaste
Differential Revision: https://reviews.freebsd.org/D59343
This fixes the build with gcc 14:
/usr/src/contrib/kyua/engine/prepare/prepare_all.cpp:56:16: error: declaration of 'handler' shadows a member of 'engine::prepare::prepare_all' [-Werror=shadow]
56 | for (auto& handler : prepare::handlers()) {
| ^~~~~~~
In file included from /usr/src/contrib/kyua/engine/prepare/prepare_all.hpp:35,
from /usr/src/contrib/kyua/engine/prepare/prepare_all.cpp:29:
/usr/src/contrib/kyua/engine/prepare/prepare.hpp:51:15: note: shadowed declaration is here
51 | class handler {
| ^
Fixes: edb230c4af
Reviewed by: igoro, rlibby, ngie
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59346
While here, s/PR#2411/NetBSD PR#2411/ in the comments for clarity.
I had to go to netbsd sources to get this information.
MFC after: 3 days
Event: Berlin Hackathon 202609
+ wrap some long lines
+ escape some ? wildcards
+ no macros in width specifiers
+ mention the speed in HARDWARE (bumps date)
+ use the hyperlink macro for... the defunct LSI website...
+ write out a symbol heavy error message format string in mdoc
MFC after: 3 days
Event: Berlin Hackathon 202609
Define __WCHAR_WIDTH in sys/_types.h and derive WCHAR_WIDTH from
that, the same way as WCHAR_MIN and WCHAR_MAX, in both <wchar.h>
and <stdint.h> as per C23 §7.31.1 and §7.22.3.4, respectively.
Reviewed by: fuz
Approved by: fuz (mentor)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D59385
Add a new CPU-family `show pcpu` handler, cpu_db_show_mdpcpu() to dump
CPU-specific PCPU data. Only Book-E is populated for now, but AIM may
be populated later.
These new field prints: save areas, TLB miss nesting, the new critical
stack pointer. All of them have been very useful for debugging very
esoteric bugs, so make them easier to see from DDB, instead of having to
rummage through hex dumps.
When a TLB miss exception occurs the exception handler must walk the
page table from the root. When the root is allocated from KVA the TLB
miss exception may take another exception if the root page(s) aren't in
the TLB.
The 64-bit page table is modeled after the AIM radix page table, with a
64kB root "page", so 16 pages. This makes regular use of UMA
allocations unable to refer back to the DMAP, which itself is mapped in
TLB1. Now we take another page from the radix pmap driver and grab
contiguous pages from the VM system, so that we can simply refer
directly to DMAP and avoid more nested TLB misses. We can still take a
nested miss, though, because the pmap itself may be in KVA, but this
reduces the nesting.
If a pmap is freed and its memory is reused before its TID reference is
taken, then arbitrary memory will be clobbered. Avoid this by never
dereferencing the pmap pointer in the tidbusy array, and instead using
it as a compare sentinel.
There's a small window between when the SRR* registers are restore and
the exception returns, in which a TLB miss exception may be triggered.
Since there are not special SRR* registers for TLB miss exceptions, the
registers from the frame will be ovwritten, and the FRAME_LEAVE block
will effectively be re-entered on exit, leading to a very hard to
diagnose panic or wedge.
Minimize this chance by pushing the SRR* restore to the last possible
moments, caching them in a PCPU save area instead until the end. This
matches what the AIM side already does.
A critical exception, such as a watchdog, can trigger at any time,
including the middle of a standard exception prologue or epilogue, so
GPRs, including %r1 (the stack pointer) cannot be trusted at all.
Instead, use a private stack pointer for critical interrupts. Each CPU
now has its own critical exception stack, with the boot stack in the
bss.
There are 4 options for e500 watchdog timeout, which may be core- or
even SoC- specific. Add support to tune the behavior via a tunable
(machdep.watchdog_mode). The tunable value is an integer 0-3.
In dma_sync_single_for_cpu(), the DMA_BIDIRECTIONAL direction currently
performs BUS_DMASYNC_POSTREAD followed by BUS_DMASYNC_PREREAD. This
patch corrects the mapping to use BUS_DMASYNC_POSTREAD |
BUS_DMASYNC_POSTWRITE.
When ownership of the DMA area is transferred to the CPU, we must assume
the previous device access was bidirectional. Both POST operations are
necessary to ensure the CPU sees a consistent view of memory after
potential device reads and writes. A PREREAD is unnecessary here because
the device will no longer access the memory since ownership has been
transferred to the CPU.
Conversely, for dma_sync_single_for_device(), ownership is being
transferred back to the hardware. The buffer must be prepared for
potential bidirectional access by the device, requiring
BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE.
PR: 293381, 297155
Reported by: Zishun Yi <[email protected]>
Reported by: Kim Shrier (fbsdbugs westryn.net)
Fixes: 95edb10b47 ("LinuxKPI: implement dma_sync_single_for_*, apply to (un)map single/sg")
Signed-off-by: Zishun Yi <[email protected]>
Reviewed by: aokblast, bz
Differential Revision: https://reviews.freebsd.org/D55497
- consistently use Mt request within Aq. This makes author
e-mail addresses clickable in many frontends.
- @freebsd.org -> @FreeBSD.org
- ([email protected]) -> Aq Mt [email protected]
Event: Berlin Hackathon 202609
MFC after: 3 days
Reviewed by: ziaee
Differential Revision: https://reviews.freebsd.org/D59410
ATF_TESTS_C automatically adds the appropriate library to LDADD --
there's no need to manually append the same library.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D59411
Commit 50c1240ebf moved the offset parsing into the PART_KIND_FILE case of
the switch, leaving PART_KIND_SIZE with no offset handling.
The offset was then silently ignored, so "-p efi::$size:$start" as used by
release/${ARCH}/mkisoimages.sh packed the ESP immediately after the preceding
partition.
Parse the offset outside the switch so both forms honour it.
Add tests covering absolute and relative offsets in both forms.
Reviewed by: jrtc27, bsdimp, jlduran
Approved by: jlduran, bsdimp
Sponsored by: Netflix
Assisted-by: Claude Code (Opus 5)
If an explicit loader wasn't requested, then bhyveload(8) maintains a
/boot handle that it can use for swapping to a different flavor. This
means that we expose all of the host /boot to the sandbox for the
duration of script execution.
Add a callback to ack that we're OK with the interpreter so that
bhyveload(8) can release the bootfd. This is worth doing because it's
prior to guest script execution, so we're still running a reasonably
untainted process.
Reviewed by: imp, jhb
Differential Revision: https://reviews.freebsd.org/D58771
crontab -r only unlinks the crontab file, so spawn it directly with
unlinkat() relative to conf.rootfd. This also makes the crontab
removal work with pw -R.
MFC After: 1 week
rmat() used stat() with a path relative to the current working
directory, so it never found the job files in /var/at/jobs and the
at(1) jobs of a deleted user were never removed.
ef7d0eb948 also broke it by introducing a typo: /usr/sbin/atrm instead
of /usr/bin/artm.
Use fstatat() with the directory fd to stat the job files relative to
the at jobs directory, and unlinkat() them directly instead of spawning
atrm.
Those changes allow us to make it works with pw -R.
MFC After: 1 week
bufinit() inserts newly initialized bufs into the QUEUE_EMPTY queue, at
which point they haven't yet been assigned a domain. Thus, bufdomain()
returns &bdomain[-1], which trips the array-bounds sanitizer.
This is harmless since we don't use the result in that case, but let's
avoid the invalid access to begin with. This is sufficient to let an
amd64 kernel boot to a login prompt with -fsanitize=array-bounds
configured.
Reported by: Andrew Griffiths <[email protected]>
Reviewed by: rlibby, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D59381
On ll/sc architectures casueword32() may report a spurious
store-conditional failure (reservation lost to an interrupt, preemption,
or another CPU touching the same reservation granule), and this is
indistinguishable from a genuine comparison mismatch: both return 1.
That is intentional since D20772 and documented in casueword(9) ("The
store can fail on load-linked/store-conditional architectures."), so
callers must cope.
do_lock_normal() does not fully cope. When the initial
UMUTEX_UNOWNED -> id acquire CAS fails spuriously, the observed owner is
still UMUTEX_UNOWNED, so neither the UMUTEX_CONTESTED branch nor the
real-owner case applies, and execution falls through past the "rv == 1
but not contested, likely store failure" comment into the sleep path.
There, the contested-bit CAS (expecting the observed owner, i.e.
UMUTEX_UNOWNED) succeeds because the mutex really is unowned, stamping
m_owner = UMUTEX_CONTESTED with no owner tid, and the thread sleeps on
"umtxn" forever: nobody owns the mutex, so no unlock and no wakeup ever
arrive. In _UMUTEX_TRY mode the same situation returns a false EBUSY
for a free mutex.
Treat an observed owner of UMUTEX_UNOWNED like UMUTEX_CONTESTED: try to
acquire the mutex, setting the contested bit, instead of falling through
to the sleep path. rv == 1 with the observed value equal to the
expected value can only mean a spurious store failure, so the mutex is
free. If the acquire CAS fails again, the outer loop restarts and
re-evaluates ownership. The contested bit set with no waiters present
only costs the matching unlock one trip through the kernel.
This was hit in practice on powerpc64le (POWER9): the Swift runtime's
Synchronization.Mutex issues _umtx_op(UMTX_OP_MUTEX_LOCK) directly with
no userspace fast path, so an uncontended lock of an unowned mutex runs
the kernel CAS exactly where a spurious failure deadlocks
(single-threaded process parked on "umtxn" with m_owner == 0x80000000,
observed as Foundation.Process.run() hanging). libthr mostly masks the
bug because pthread_mutex_lock() enters the kernel only when there is a
real owner that will eventually issue a wakeup.
The mechanism was confirmed with an experimental powerpc kernel that
instead retried the ll/sc sequence inside casueword32()/casueword();
that also eliminated the hang, but is not proposed here since the
single-attempt semantics of casueword(9) are intentional.
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D59338
All other usages of SCF_SIGNATURE are protected by IPSEC_SUPPORT
or TCP_SIGNATURE.
No functional change intended.
Reported by: Hannes Elfert
MFC after: 1 week
MFC to: stable/14
MFC to: stable/15
When processing the ACK of the initial TCP handshake using the
SYN cookie, don't increment the counter for unexpected
signatures (tcps_sig_err_sigopt). The correct
counter (tcps_sig_rcvbadsig) for bad signatures is already
incremented in TCPMD5_INPUT().
Reported by: Hannes Elfert
Reviewed by: rscheff
MFC after: 1 week
MFC to: stable/14
MFC to: stable/15
Differential Revision: https://reviews.freebsd.org/D59302
Wake-on-LAN capability was inferred from NVM bits on every MAC even
though 82599 support is board and sometimes port specific. Private
sysctls formed a second policy interface, and the driver neither
coordinated the controller wake source with PCI PME nor reliably
rebuilt address filters erased by the stop-time reset.
Use the standard ifconfig wake capabilities. Derive support from the
82599 board and port matrix or the X540-and-newer NVM capability.
Require D3hot PME support, and use the NVM APME bit only to select the
initial magic-packet policy after initializing the LAN function number.
Snapshot requested filters before the terminal stop so shared reset and
PHY code sees the active wake policy. After reset, restore RAR0, the
multicast table, receive filtering, and the optical laser before arming
WUFC, WUC, and PCI PME. Remove device wake sources before clearing PCI
PME on detach, resume, and when wake is disabled. Clear autonomous APM
so ifconfig remains authoritative.
Treat X550EM low-power-link-up failure as best effort and allow shutdown
to continue after a wake-programming error.
The 82599, X540, X550, and E610 datasheets document the standard ACPI
wake filters used here; the E610 ACPI path includes magic-packet wake.
Validated on a dual-port E610. Both ports completed three direct-D3
cycles covering wake disabled and magic-packet wake armed. A system S3
cycle woke through ix0 with WUS 0x00000002 (magic packet). Link and
traffic recovered after each transition.
Note that many add-in cards in this family do not support WoL; LOM and
OCP cards are more likely. The E610 as tested does.
MFC after: 2 weeks
Sponsored by: Dirk-Willem van Gulik from Web Weaving (E610 hardware)
Sponsored by: BBOX.io
When receiving a SYN segment with an MD5 option on a listening socket,
which has not enabled TCP MD5 support, increment the counter for
unexpected signatures (tcps_sig_err_sigopt).
Reviewed by: rscheff
MFC after: 1 week
MFC to: stable/14
MFC to: stable/15
Differential Revision: https://reviews.freebsd.org/D59303
Whenever we create a user-space mapping, we always set ATTR_S1_PXN in
the PTE, which blocks execution of user-space code while running in
kernel mode. However, when seeking to determine whether we need to
perform an icache flush before installing the new PTE, we test whether
sometimes the old PTE or other times the new PTE has ATTR_S1_XN set.
The trouble is that ATTR_S1_XN is defined as the bitwise OR of
ATTR_S1_PXN and ATTR_S1_UXN, and so the test for whether ATTR_S1_XN is
set is satisfied if either of its constituent bits is set, i.e., we
write (l3e & ATTR_S1_XN) != 0. Consequently, the test is always true.
In practice, I believe that the ill effects of this bug are limited:
In pmap_enter(), in rare circumstances, e.g., wiring a code page, an
unnecessary icache flush will be performed. In pmap_enter_l2() and
pmap_enter_l3c(), no icache flush will be performed. However,
typically an icache flush would have already been performed on each of
the constituent base pages.
Reviewed by: kib, markj
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D59265
Konstantin Belousov