This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project main llvmorg-21-init-19288-gface93e724f4, the
last commit before the upstream release/21.x branch was created.
PR: 292067
MFC after: 1 month
This reverts commit a7455c47801ea1e4c4eed10cab2072375f6f92a2, in
preparation for merging llvm 21, in preparation for merging llvm 21.
PR: 292067
MFC after: 1 month
Things like `{ some_program; } >/dev/null` use vfork, so use vfork
similarly for things like `some_program >/dev/null`.
This cannot be done for command substitutions, because of two problems:
* Redirections might cause the error message for later redirections or
for an unknown command to be sent to the pipe (to be substituted), and
this might cause a deadlock if the message is too long.
* The assignment of the pipe needs to come before instead of after the
redirections.
Reviewed by: bdrewery
Differential Revision: https://reviews.freebsd.org/D55190
The RPC client is more of a class rather than an instance. RPCs from
different VNETs are served by the same client. This makes the kgss layer
fully transparent to VIMAGE and not even required to be aware of it.
It is responsibility of the rpcsec_gss module to have curvnet set on the
calling thread when doing RPC calls via kgssapi.
This change should enable proper operation of an NFS server with gssd(8)
in a VIMAGE jail.
PR: 294501
Reviewed by: rmacklem
Differential Revision: https://reviews.freebsd.org/D56562
These RPC methods correctly acquire the kgss_gssd_handle later with call
to kgss_gssd_client().
Reviewed by: rmacklem
Differential Revision: https://reviews.freebsd.org/D56561
The original idea was that something else than VNET(9) might be used for
kgss in jails, but that is very unlikely to happen.
Mechanical change done with sed+grep. No functional change.
Reviewed by: rmacklem
Differential Revision: https://reviews.freebsd.org/D56560
We had ENA_RX_BUDGET = 256 in order to allow up to 256 received
packets to be processed before we do other cleanups (handling tx
packets and, critically, refilling the rx buffer ring). Since the
ring holds 1024 buffers by default, this was fine for normal packets:
We refill the ring when it falls below 7/8 full, and even with a large
burst of incoming packets allowing it to fall by another 1/4 before we
consider refilling the ring still leaves it at 7/8 - 1/4 = 5/8 full.
With jumbos, the story is different: A 9k jumbo (as is used by default
within the EC2 network) consumes 3 descriptors, so a single rx cleanup
pass can consume 3/4 of the default-sized rx ring; if the rx buffer
ring wasn't completely full before a packet burst arrives, this puts
us perilously close to running out of rx buffers.
This precise failure mode has been observed on some EC2 instance types
within a Cluster Placement Group, resulting in the nominal 10 Gbps
single-flow throughput between instances dropping to ~100 Mbps as a
result of repeated rx overruns causing packet loss and ultimately
retransmission timeouts.
To correct this, switch from processing up to ENA_RX_BUDGET (256)
packets to processing up to ENA_RX_DESC_BUDGET (256) descriptors (or
slightly more, if we hit the limit in the middle of a packet). This
ensures that, even with jumbos, we refill the ring before processing
most of a ring worth of descriptors, and returns the throughput to
expected levels.
Note that theoretically up to ENA_PKT_MAX_BUFS (19) descriptors can be
used for a single packet, in which case even 54 packets would exhaust
the default rx buffer ring; it's not clear if this ever occurs in
practice, but this fix will address that case as well.
Reviewed by: akiyano
Sponsored by: Amazon
MFC after: 6 days
Differential Revision: https://reviews.freebsd.org/D56479
The ena_[rt]x_cleanup functions are limited internally to a maximum
number of packets; this ensures that TX doesn't starve RX (or vice
versa) and also attempts to ensure that we get a chance to refill
the RX buffer ring before the device runs out of buffers and starts
dropping packets.
Historically these functions have returned the number of packets which
they processed which ena_cleanup compares to their respective budgets
to decide whether to reinvoke them. This is unnecessary complication;
since the precise number of packets processed is never used, adjust
the APIs of those functions to return a bool indicating if they want
to be reinvoked (aka if they hit their limits).
Since ena_tx_cleanup now only uses work_done if diagnostics are
enabled (ena_log_io macros to nothing otherwise) eliminate that
variable and pass its value (ENA_TX_BUDGET - budget) to ena_log_io
directly.
No functional change intended; this will simplify a future commit.
Reviewed by: akiyano
Sponsored by: Amazon
MFC after: 6 days
Differential Revision: https://reviews.freebsd.org/D56478
- Rename `.Nm .rhosts` to `.Nm rhosts` to match the MLINK for the
manpage.
- Use `.Pa` instead of `.Nm` when discussing the paths for `.rhosts` and
`hosts.equiv.5` for explicitness and clarity.
Bump .Dd for the change.
MFC after: 1 week
- Add `.Nm` section for securelevel(7) to match corresponding MLINKS entry.
- Fix the spelling for mac(4) (the actual subsystem manpage is spelled out in
lowercase.
MFC after: 1 week
During a discussion about using -fms-extensions jhb pointed out that
we have them enabled in the kernel for gcc by default (even multiple
times in one part). I had missed all that and clang still failed on
my use case (needing another option).
The original cause for enabling them for our tree back then was that
we needed to support C11 anonymous struct/unions.
Our in-tree gcc 4.2.1, despite later patches, needed the
-fms-extensions to support these even though this was not the expected
use case for that option ( cc4a90c445 enabled it globally for the
kernel).
clang at that time (or at least when it became default for 10.0)
already was fine (with C11).
Any later gcc (4.6.0 onwards) did not need that option anymore, even
when compiled for -std=iso9899:1990 (which does not support anonymous
structs/unions) unless one would add -pedantic (see gcc git 4bdd0a60b27a).
This is also the reason why userland cddl sources now compile with the
option removed despite CSTD=c99.
The only driver which needed the option recently was ccp, but that was
fixed in 8d3f41dbcb by jhb.
So cleanup all uses cases of -fms-extensions for the moment as they are
no longer needed given all compilers currently supported seem to be
fine without them and gcc-4.2.1 was removed from the tree in stable/13
in 2020 (a9854bc381).
Reported by: jhb (all this but possibly the world CDDL parts)
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: emaste (earlier), imp, jhb, glebius
Differential Revision: https://reviews.freebsd.org/D55072
It turns out interface ioctls are defined not just in sockio.h, but are
spread among many files. When I added SIOCGI2CPB at the bottom of the
file, the next number (160) collided with an ioctl (IPSECGREQID) that
I was unaware of in another file. Fix this by moving to a number that
is unclaimed.
Fixes: cf1f215728 (net: Add SIOCGI2CPB ioctl & add page/bank fields to ifi2creq)
Reported by: dhw
Reviewed by: imp
Non-stroage drives have namespaces, but no storage attached. These
drives have a different interface type than storage drives, so ignore
them for the nvme_sim, which just handles storage.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D56461
Create a tunable for the maxinum number of 'high power' commands to
schedule, kern.cam.max_high_power. Default remains at 4.
Differential Revision: https://reviews.freebsd.org/D56462
XPT_GDEVLIST in xpt_action_default has two early-return paths (list
changed and index not found) that set cgdl->status but not ccb_h.status.
Since xpt_action sets ccb_h.status to CAM_REQ_INPROG before dispatching,
and XPT_GDEVLIST is an non-queued CCB, cam_periph_ccbwait skips the
sleep loop and immediately hits the KASSERT checking that status !=
CAM_REQ_INPROG, causing a panic.
Set ccb_h.status = CAM_REQ_CMP at the top of the code rather than the
bottom. Any future error paths will be right (since this command can't
fail at the command level, just in the status of the data level).
PR: 293899
Assisted-By: Claude Opus 4.6 (1M context)
Sponsored by: Netflix
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D56487
The pass(4) driver's CAMIOCOMMAND and CAMIOQUEUE ioctls accept arbitrary
CCBs from userland. This device requires root to open, and thus send
these commands. Previously, the only func_code filter was a blocklist
check against the XPT_FC_XPT_ONLY flag. This missed several dangerous
func_codes that lack that flag:
- XPT_ABORT: the abort_ccb field is a raw kernel pointer from the
user CCB payload. xpt_action_default() dereferences it without
validation, leading to kernel crashes or worse.
- XPT_SASYNC_CB: the callback and callback_arg fields come directly
from the user CCB payload and get registered as a kernel async
callback, allowing arbitrary kernel code execution.
- Target mode CCBs (XPT_EN_LUN, XPT_TARGET_IO, etc.) fall through
directly to the SIM with user-controlled payloads.
Replace the XPT_FC_XPT_ONLY blocklist with an explicit allowlist of CCB
function codes that are known to be safe for userland to submit: I/O
operations (SCSI, ATA, NVMe, SMP, MMC), device queries, transport
settings, and a handful of safe control operations (NOOP, REL_SIMQ,
RESET_DEV, DEBUG). Normally, the /dev/pass* permissions only allow root
to access them, so this is only a safety issue by default.
Also reject CAM_DATA_PADDR and CAM_DATA_SG_PADDR, since these pass
user-supplied physical addresses directly to DMA with no validation,
which on systems without an IOMMU allows arbitrary host memory access.
Add `options PASS_UNSAFE_PADDR` to allow the old behavior.
Verified that camdd, camcontrol, smartmontools, and cdrtools use only
func_codes on the allowlist (XPT_SCSI_IO, XPT_ATA_IO, XPT_NVME_IO,
XPT_NVME_ADMIN, XPT_PATH_INQ, XPT_GDEV_TYPE, XPT_GET_TRAN_SETTINGS,
XPT_SET_TRAN_SETTINGS, XPT_RESET_DEV, XPT_DEBUG) and none use
CAM_DATA_PADDR.
PR: 293888, 293890
Assisted-By: Claude Opus 4.6 (1M context)
Sponsored by: Netflix
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D56486
Prior to this patch, a thread would get EBUSY on open(2) if another
thread had the speaker open.
With this patch, two or more threads/processes can use the speaker
device at the same time. When two or more threads write to the speaker
concurrently, individual melodies--single strings, as written by
write(2) or ioctl(2) with command SPKRTONE/SPKRTUNE--are played
atomically.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1922
When the frequency configuration logic was moved to clock.c in 2008, a
mutex lock was added there (timer_spkr_setfreq) to serialize accesses
to the I/O register.
Since then, no more calls to disable/enable_intr were needed in spkr.c
than they were needed in the other callers to the same timer_spkr
functions in syscons / kern_cons, that is, not at all. This is because
there are no other accesses remaining in the kernel to the i8254
timers after boot than through clock.c.
For context, see commits
e465985885
and
93f5134aaf.
Signed-off-by: Raphael Poss <knz@thaumogen.net>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1922
Remove the perfmon performance monitoring facility that was for Intel
Pentium and Pentium Pro processors.
Reviewed by: imp,mhorne,emaste
Pull Request: https://github.com/freebsd/freebsd-src/pull/2155
Ensure that the optional MSRs and the user flags are guarded by the
cpuid feature flags. This prevents the user from triggering undefined
behavior or crashes on AMD processors where some of these features are
not present. As part of this, I added the branch target and DATA4 MSRs
to the IBS op state as those are only present on a subset of the Zen
chips that I have tested.
Reviewed by: mhorne
Sponsored by: Netflix
Pull Request: https://github.com/freebsd/freebsd-src/pull/2133
Instead of driving the world package build from Makefile.inc1,
use a subdir build where each package has a subdirectory under
packages/ using the new <bsd.pkg.mk>.
Convert some metadata that was previously in the UCL files (e.g.
sets and dependencies) to Makefile variables.
Build the packages under objdir (not repodir), and use the new
stagepackages target to copy them to repodir when creating the
repository.
Determine an explicit list of packages to build in packages/Makefile
based on enabled src.conf options, and add logic to abort the build
if we attempt to build an empty package. This inverts the previous
logic in Makefile.inc1 which would simply skip empty packages.
There are a few advantages to doing it this way:
* The package build works more like the rest of the build system,
so it's more accessible to developers.
* We can customise the packages we build based on src.conf options,
e.g. skipping a package entirely, or adjusting its dependencies
based on what it actually requires.
* We have a specific list of packages that we want to build, and an
unexpectedly missing package results in a build error, instead of
silently producing a broken repository.
* It's possible to build (and in the future, install) an individual
package without having to rebuild the entire repository.
This doesn't apply to the dtb, kernel-* or src-* packages; those
have their own build systems in Makefile.inc1 and will be converted
later.
MFC after: 4 weeks (stable/15 only)
Reviewed by: jlduran, sjg, brooks
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D56087
Dimitry Andric