xdr: Fix xdr_string
Forcing maxsize to RPC_MAXDATASIZE breaks code that deliberately uses
XDR with longer strings than permitted by SunRPC.
MFC after: 1 week
Fixes: 6448ec89e739 (" * limit size of buffers to RPC_MAXDATASIZE")
Fixes: e17d7ab869bb ("xdr_string: don't leak strings with xdr_free")
Sponsored by: Klara, Inc.
Sponsored by: NetApp, Inc.
Reviewed by: kevans, brooks
Differential Revision: https://reviews.freebsd.org/D59994
(cherry picked from commit d2018cedb414ef17e77b7fc2fa19fd81328da46b)
xdr: Limit xdr_wrapstring
The previous commit (re)introduced the possibility that a malicious or
corrupt message can cause the receiver to allocate a very large amount
[11 lines not shown]
xdr_string: don't leak strings with xdr_free
Historically (and in a small amount of older software such as OpenAFS),
developers would attempt to free XDR strings with
xdr_free((xdrproc_t)xdr_string, &string)
This resulted in xdr_free calling xdr_string with only two intentional
arguments and whatever was left in the third argument register. If the
register held a sufficently small number, xdr_string would return FALSE
and not free the string (no one checks the return values).
Software should instead free strings with:
xdr_free((xdrproc_t)xdr_wrapstring, &string)
Because buggy software exists in the wild, act as though xdr_wrapstring
was used in the XDR_FREE case and plug these leaks.
[9 lines not shown]
website: Add 2027 events
Oh yeah, that's right, none of this "two weeks out" update,
we're adding the whole entire 2027, and it's still 2026 :)
Some of these do not have a finalized date and will need attention.
Reviewed by: bcr, hrs
Discussed with: adrian, cperciva
Differential Revision: https://reviews.freebsd.org/D61237
aio_mlock.2: Expand document description
+ The old one renders broken because Xr is not correct/portable in Nd
+ Take this opportunity to explain it better using mlock description
MFC after: 3 days
Reviewed by: glebius
Differential Revision: https://reviews.freebsd.org/D61334
tests/sys/kern/ssl_sendfile: double timeouts for :grow and :truncate
The :grow and :truncate testcases fail semi-regularly in CI with
timeouts. Double the timeout to reduce false positives with the tests.
PR: 300699
MFC after: 1 week
Reviewed by: siva
Differential Revision: https://reviews.freebsd.org/D61444
asmc: include sys/kernel.h
This is needed for the `MODULE*` macros.
This include was accidentally removed in the linked commit.
MFC after: 1 week
Reported by: Ian Freislich <ianfreislich at gmail.com>
Fixes: c714cde179a4 ("asmc: split the sysctl layer into asmcsysctl.c")
iflib: Use a single tx dma map
The need for a separate map for TSO and non-TSO seems to have arisen from
a misunderstanding about the DMA requirements for Intel drivers like
ice/ixl/iavf. Specifically, this Intel hardware has a quirk where no
more than N (=8) segs can be DMA'ed per packet on the wire. This limit
was enforced using a DMA map with a low segment limit for non-TSO and a
driver specific check for TSO. This led to a *lot* of complexity in
iflib (~80 extra lines of code that this change removes) when the
limit can simply be enforced via the existing EFBIG mechanisms.
This change adds a new flag, IFLIB_SPARSE_TX, that drivers for hardware
with this quirk must set. When set, it causes non-TSO sends that
exceed isc_tx_nsegment to be treated as if bus_dmamap_load_mbuf_sg()
had returned EFBIG.
Due to the API/KABI change, I've bumped the FreeBSD version as well.
Note kgalazka suggested the flag, rather than a more awkward
[12 lines not shown]
snmp_hostres(3): strengthen work on the devd(8) socket
Use the SOCK_SEQPACKET version of the socket. This guarantees that
messages read won't be glued together. Use sufficient buffer size to
read any message.
Close socket on any kind of error or a short read.
This also fixes a bug when a SOCK_STREAM socket containing exactly
multiple of 512 bytes would block the daemon in read(2) until some
other devd(8) event. Thank to David for catching and analyzing it.
Reported by: David Pfitzner <dpfitzner at netflix.com>
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D61146
devd: expose maximum record size via sysconf(3)
Use UMA allocation size that holds the buffer. The buffer is actually
slightly smaller. Document the latter so that clients don't need to use
+1 if they later want to NUL-terminate a message.
Reviewed by: mjg, imp
Differential Revision: https://reviews.freebsd.org/D61346
devd: define _PATH_DEVD_SOCKET in <paths.h>
Sweep through consumers and use the define.
Reviewed by: kfv, imp
Differential Revision: https://reviews.freebsd.org/D61344
iflib: simplify TXQ_AVAIL
Simply the TXQ_AVAIL() macro to avoid using
get_inuse(txq->ift_size, txq->ift_cidx, txq->ift_pidx, txq->ift_gen)
and instead define it in terms of txq->ift_in_use.
Note that in_use is equivalent, because it is updated at the same time
as cidx/pidx and gen, and under the same serialization. The advantage
is that its cheaper due to using one read and no branches, and
safer, since unlocked reads get an atomic snapshot of availability,
but an unlocked read of multiple counters can produce inconsistent
results.
Reviewed by: kbowling, kgalazka
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D61279
(cherry picked from commit 44df82b11c535ae50b1e5888a361a2bd15d4182b)
iflib: rate limit deferred tx ring drain
When simple_tx gives up & return ENOBUFS because the tx ring is full,
we were doing a GROUPTASK_ENQUEUE(&txq->ift_task) each time.
On a tx ring that has overflowed and is being hammered on
by a fast UDP sender, this can result in a massive increase in
context switches (I've seen over 30M ctxw/sec due to this, and
the ctxsw codepath taking roughly 50% CPU).
This change removes the GROUPTASK_ENQUEUE() and replaces it
with a call to a callout which drains the tx ring. The callout time is
determined based on the link speed, estimating how long it would take
for a large fraction of of a ring containing full-MTU packets to drain.
This removes the 30M ctxsw / sec in my test case and reduces it
to roughly a doubling of ctxsws.
Reviewed by: kbowling
Sponsored by: Netflix
[3 lines not shown]
tpm: crb: Support the ACPI start method
Some AMD firmware TPMs report StartMethod 2 and had no driver. They never
acknowledge CTRL_REQ, so skip the idle and ready requests.
Do not harvest entropy from these TPMs on AMD: on a Ryzen 7 7735HS each
periodic TPM2_GetRandom froze every CPU, for up to 1.2 s (AMD PA-410).
Reviewed by: kbowling
Approved by: kbowling
Differential Revision: https://ron-dev.freebsd.org/FreeBSD/src/pulls/103
(cherry picked from commit 6af18560a124b84549713a5f2b667a1df0990929)
