mfc-candidates: Annotate variables as local
And clean up luacheck warnings.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D48950
Revert "ciss: Add max physical target"
This reverts commit 45645518ea19ccb4761aee3a525aab2f323d37d4.
Although this changed looks like it should just be a harmless change to
bookkeeping, it turns out that it changes the termination condition of
the initial device scan, resulting in it never finishing. This causes
the boot to hang forever coming up. Since I don't have good access to
hardware, I'm reverting until the exact details can be sorted out.
Reported by: Edward Scroop
Sponsored by: Netflix
MFC After: 1 week
yppush: Add SPDX-License-Identifier tag
Reviewed by: emaste
Sponsored by: The FreeBSD Foundation
(cherry picked from commit d6bec77ad8f80438f10bb3fe7a8bc8e9265e2858)
beep: Add SPDX-License-Identifier tag
Reviewed by: emaste
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 7e313584ab1075195ab735c1452375cf2388b162)
diff: Add SPDX-License-Identifier tag
Reviewed by: emaste
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 878cee8d9b9b4c7c5530b0960306c04b1b691325)
tests/libc: Fix fortify_source uio tests
Some of the preadv() and readv() tests were not initializing the iovecs
they pass to the system call. When the system call is expected to fail,
that's fine since the FORTIFY_SOURCE checks cause the process to be
aborted. However, in the rest of the test cases, the (p)readv() call
could cause spurious test failures, e.g., when an uninitialized iov
entry points to the current stack frame and the canary gets overwritten.
Modify the tests to explicitly initialize iov entries to avoid this.
The "iov" variants don't have this problem, so leave them alone.
Reviewed by: kevans
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58289
(cherry picked from commit 1719b754a9ec88fcf0f5f4b001b1b5d5d6db5819)
gve: Implement AQ batching for queue creation and destruction
Currently, the FreeBSD driver configures and destroys queues
sequentially by issuing individual Admin Queue (AQ) commands.
During queue teardown (e.g., interface reset), disabling queues
one by one leaves the device in a partially configured state.
Because the device does not yet know that the driver is in the
process of fully unconfiguring all queues, this intermediate
state can trigger transient error logs (such as when queue 0 is
disabled while other queues are still active).
Modify the driver to use Admin Queue batching for both the
creation and destruction of TX and RX queues. Commands are now
queued and kicked together, ensuring the queue configuration changes
are applied atomically and preventing transient errors from being logged.
Signed-off-by: Sujithra Periasamy <sujithra at google.com>
[6 lines not shown]
rawip: Fix handling of checksums in rip6_input()
A v6 raw socket may ask the kernel to validate the checksum of an
inbound packet. If it does, and the validation fails, we discard the
packet, but this isn't really right: other raw sockets may wish to
receive a copy of the packet anyway.
Rework checksum handling to address this problem, and use a flag to
avoid computing the checksum more than once for a given packet.
Fixes: de2d47842e880281 ("SMR protection for inpcbs")
Reviewed by: pouria, glebius
Reported by: Yunzhi Ke
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58559
(cherry picked from commit 196874ce2e97e3e6425493b1d501e716b356bc36)
bhyve: tpm: Avoid printing a message when clearing the cancel bit
Some drivers do this routinely, e.g., FreeBSD's tpm20 does this every
time it sends a command in tpmcrb_transmit(). This causes the console
to fill up with messages. Instead, only print a warning if the cancel
bit is set to one.
Reviewed by: corvink
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D52425
(cherry picked from commit 1c1a3646a1c86624e67a42636894fd1685386cf1)
epoch: Fix epoch_drain_callbacks()
This function is supposed to wait until all pending callbacks have been
executed. This is useful in some contexts where we tear down some
context (like a VNET jail and its associated UMA zones) synchronously,
and we want to make sure that all pending asynchronous callbacks (which
may free objects to said UMA zones) have run first.
The implementation schedules a callback on each CPU and waits for them
all to run. This assumes that, on a given CPU, callbacks are executed
in the order that they are pushed. This assumption depends on the
implementation of epoch_call_task() and ck_epoch_poll_deferred(), and it
is not true in general.
Callbacks are pushed onto a per-CPU stack in LIFO order.
ck_epoch_poll_deferred() first pulls out the callbacks from epoch - 2,
which are always safe to execute, and in so doing reorders them such
that the oldest callback as at the top of the stack, so in this case,
epoch_call_task() will execute them in order. However,
[24 lines not shown]
proc: Copy the p_reapsubtree field explicitly during fork
p_reapsubtree lives in the p_startcopy/p_endcopy block of struct proc,
which is copied during fork without any synchronization. However, the
field is not stable except when the proctree lock is held, and indeed
may change if p1's reaper exits or explicitly releases its reaper
status. This state change can race with fork() and leave the child with
an incorrect p_reapsubtree field.
Close the race: explicitly copy the field under the proctree lock during
fork.
Reported by: syzkaller
Reviewed by: kib
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58482
(cherry picked from commit 8616b7dc3850758eb39a5b63f41f56c05403380b)
