ipfw: pmod: avoid further rule processing after tcp-mod failures
m_pullup() here will have freed the mbuf chain, but we pass back an
IP_FW_DENY without any signal that the outer loop should finish. Thus,
rule processing continues without an mbuf and there's a chance that we
conclude that the packet may pass (but there's no mbuf remaining)
depending on the rules that follow it.
PR: 284606
Reviewed by: ae
(cherry picked from commit c0382512bfce872102d213b9bc2550de0bc30b67)
ipfw: pmod: avoid further rule processing after tcp-mod failures
m_pullup() here will have freed the mbuf chain, but we pass back an
IP_FW_DENY without any signal that the outer loop should finish. Thus,
rule processing continues without an mbuf and there's a chance that we
conclude that the packet may pass (but there's no mbuf remaining)
depending on the rules that follow it.
PR: 284606
Reviewed by: ae
(cherry picked from commit c0382512bfce872102d213b9bc2550de0bc30b67)
release: Make fetch happen in GCE images
We want to fetch distfiles, regardless of whether they contain known
vulnerabilities or we're building images for a different version of
FreeBSD.
Reviewed by: ivy
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D53569
release: Don't try to fetch distfiles for pkgbase
In order to comply with the require that GCE images must include their
source code, we fetch distfiles for all of the packages installed into
GCE images. This fails for obvious reasons for packages with an origin
of base/*; filter those out to generate the list to fetch.
Reviewed by: ivy
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D53568
release: GCE builds depend on ftp
GCE images are required by Google to include their source code; we do
this by extracting {src,ports}.txz into the images, from the (legacy)
distribution sets.
Make sure those distribution sets actually exist.
Reviewed by: ivy
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D53567
graphics/mesa-devel: unbreak build on aarch64 around 9557360d5a11
FAILED: [code=1] src/gallium/targets/rusticl/libRusticlOpenCL.so.1.0.0
ld: error: ld-temp.o <inline asm>:3:1: symbol 'loop64' is already defined
loop64:
^
ld: error: ld-temp.o <inline asm>:3:1: symbol 'loop64' is already defined
loop64:
^
ld: error: ld-temp.o <inline asm>:3:1: symbol 'loop64' is already defined
loop64:
^
ld: error: ld-temp.o <inline asm>:3:1: symbol 'loop64' is already defined
loop64:
^
[3 lines not shown]
bhyve.8: Correct description for -c flag, tag spdx
The examples only show the usage of `-c <numcpus>`, as did the flag
description, however the -c flag supports more complex cpu topology
specifiers. These were documented correctly in SYNOPSIS, add them to
the body of the DESCRIPTION as well. Someone could go further and do
and example with using them.
MFC after: 3 days (there was a merge conflict with the date)
Event: OpenZFS Developer Summit '25
Reported by: Levi Worley <levi at gainframe.com>
(cherry picked from commit 205af037e302fbd50dabc485a89e2222cd063b9e)
Refinements to the --libxo support for geom status and list sub commands.
Changes based on comments in D53110: tags should be lowercase; rename a
few containers so that the JSON/XML output says "DISK" or "MULTIPATH"
(depending on class) instead of a generic "Geom"; adds {t:} to trim
extra whitespaces that sometimes appeared in the value fields of
JSON/XML output.
Submitted-by: Johan Söllvander
MFC-after: 1 week
Differential Revision: https://reviews.freebsd.org/D53313
nvme: Add handling for bar5
The NVMe spec allows the Table BIR (TBIR) and PBA DIR (PBIR) to
be 0, 4, or 5. The existing NVMe driver basically only has support
for 4, perhaps under the assumption that BAR4 is 64-bit and also
occupies BAR5.
This change adds support for BAR5, covering the case where BAR4
and BAR5 might both be present and 32-bit, where the Table BIR
might be 4 and the PBA BIR might be 5, or vice versa.
The NVMe spec (in the SR-IOV section) also permits VFs to use BIR=2,
so I haven't added stricter checks on which BIR will be permitted
by the driver.
This enables FreeBSD on Google Compute Engine C4 Machines.
MFC after: 3 days
Reviewed by: imp
[6 lines not shown]
vmimage.subr: pkg autoremove after pkg install
A bug in pkg, which somehow only surfaced as a consequence of pkgbase,
results in pkg install sometimes pulling in false dependencies. This
problem might be limited to cases when the lib32 pkgbase packages are
not installed. In the case of EC2 "small" images, installing the
ebsnvme-id package results in binutils, gcc12-devel, gmp, indexinfo,
liblz4, mpc, mpfr, and zstd packages being installed.
These false dependencies are however not recorded as dependencies --
at some level pkg does understand that they're not needed -- so running
pkg autoremove immediately after pkg install cleans them up.
Note: This does not remove lines from METALOG corresponding to these
packages, and makefs emits an error when it attempts to create the
filesystem but cannot find the files listed in METALOG -- but makefs
does seem to complete normally despite the error messages.
This change should be reverted once the pkg issue has been located and
[6 lines not shown]
