15.0: On (revised) schedule
BETA5 builds started on November 7th as planned.
While I'm here, fix a typo (being -> begin). [1]
Reported by: Graham Perrin [1]
Sponsored by: https://www.patreon.com/cperciva
tcp: improve comments in the syncache code
Add a comment explaining why syncache entries are dropped and fix a
typo in a comment.
Reviewed by: rrs, glebius
MFC after: 3 days
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D53564
sysutils/bareos-server: unbreak build after devel/cli11 updated from 2.5.0 to 2.6.1 (+)
cli11 update have moved some definitions to new place.
Follow it by include new source.
/wrkdirs/usr/ports/sysutils/bareos-server/work/bareos-Release-24.0.5/core/src/tools/gentestdata.cc:34:24: error: no member named 'AsSizeValue' in namespace 'CLI'
34 | ->transform(CLI::AsSizeValue{k_is_1000})
| ~~~~~^
1 error generated.
Reported by: bulk -t
Approved by: portmgr blanket (trivial build fix)
vmm: Fix a deadlock between vm_smp_rendezvous() and vcpu_lock_all()
vm_smp_rendezvous() invokes a callback on all vCPUs, blocking the
initiator until all vCPUs have responded. vcpu_lock_all() blocks each
vCPU by waiting for it to go idle and setting the vCPU state to frozen.
These two operations can deadlock on each other, particularly when
booting a Windows guest, when vcpu_lock_all() blocks waiting for a
rendezvous initiator, and the initiator is blocked waiting for the vCPU
thread which called vcpu_lock_all() to invoke the rendezvous callback.
Implement vcpu_lock_all() in a way that avoids deadlocks with
vm_smp_rendezvous(). In particular, when traversing vCPUs, invoke the
rendezvous callback on the vCPU's behalf to help the initiator finish.
We can only safely do so when the vCPU is IDLE or we have already locked
it, otherwise we may be racing with the target vCPU thread. Thus:
- Use an exclusive lock to serialize vcpu_lock_all() callers, which lets
us lock vCPUs out of order without fear of deadlock with parallel
vcpu_lock_all() callers.
- If a rendezvous is pending, lock all idle vCPUs and invoke the
[16 lines not shown]
riscv/vmm: Remove a redundant maxcpu check in vm_alloc_vcpu()
aplic_max_cpu_count() just returns the VM's max vCPU count, and
vm_alloc_vcpu() already checks that. Just remove this check so that
it's easier to merge vm_alloc_vcpu() into MI code.
If the APLIC really does require us to lower the limit, we should
instead adjust vm->maxcpu in vm_create().
No functional change intended.
Reviewed by: br
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D53496
(cherry picked from commit 5baa83cfcbd87109dc8a61fbb2e183998cc2d5c5)
virtio: Fix polling in virtqueue_dequeue()
The access of vq->vq_ring.used->idx needs to be volatile-qualified,
otherwise the compiler may optimize virtqueue_poll() into an infinite
loop if there is no data available upon the first poll.
Prior to commit ad17789a8569 this wasn't a problem since an external
function call after each poll inhibited the optimization.
PR: 289930
MFC after: 3 days
Sponsored by: Klara, Inc.
Fixes: ad17789a8569 ("virtio: Remove the unused poll method")
(cherry picked from commit f999ffdce3813eb946f10999ccffb8275c324469)
