Avoid waiting on physical allocations that can't possibly be satisfied
- Change vm_page_reclaim_contig[_domain] to return an errno instead
of a boolean. 0 indicates a successful reclaim, ENOMEM indicates
lack of available memory to reclaim, with any other error (currently
only ERANGE) indicating that reclamation is impossible for the
specified address range. Change all callers to only follow
up with vm_page_wait* in the ENOMEM case.
- Introduce vm_domainset_iter_ignore(), which marks the specified
domain as unavailable for further use by the iterator. Use this
function to ignore domains that can't possibly satisfy a physical
allocation request. Since WAITOK allocations run the iterators
repeatedly, this avoids the possibility of infinitely spinning
in domain iteration if no available domain can satisfy the
allocation request.
PR: 274252
Reported by: kevans
[13 lines not shown]
ifconfig: Enter jail as soon as possible
Some options (in particular, -g) are processed immediately upon being
parsed. This will produce the wrong result in combination with -j since
we only attach to the jail after we're done parsing arguments. Solve
this by attaching to the jail immediately when -j is encountered. The
downside is that e.g. `ifconfig -j foo -j bar` would previously attach
to jail “bar”, whereas now it will attempt to attach to jail “foo”, and
if successful, attempt to attach to jail “bar” within jail “foo”. This
may be considered a feature.
PR: 289134
MFC after: 1 week
Reviewed by: zlei
Differential Revision: https://reviews.freebsd.org/D52501
(cherry picked from commit 18fd1443d205aed6be22966125a4820f77571948)
ipfw: Check for errors from sooptcopyin() and sooptcopyout()
Note, it looks like this code may be unused since commit 4a77657cbc01
("ipfw: migrate ipfw to 32-bit size rule numbers"). In particular, it
looks like the ipfw_nat_*_ptr pointers are unused now.
Reviewed by: ae
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D53068
(cherry picked from commit 2df39ce5d4a8836ef5fd3c2666f48041042eff42)
dhclient: improve UDP checksum handling
When sending UDP packets:
* compute the checksum in the correct order. This only has an impact
if the length of the payload is odd.
* don't send packet with a checksum of zero, use 0xffff instead as
required.
When receiving UDP packets:
* don't do any computations when the checksum is zero.
* compute the checksum in the correct order. This only has an impact
if the length of the payload is odd.
* when computing the checksum, store the pseudo header checksum
* if the checksum is computed as zero, use 0xffff instead.
* also accept packets, when the checksum in the packet is the pseudo
header checksum.
The last point fixes a problem when the DHCP client runs in a VM,
the DHCP server runs on the host serving the VM and the network
interface supports transmit checksum offloading. Since dhclient
doesn't use UDP sockets but bpf devices to read the packets, the
[9 lines not shown]
sctp, tcp, udp: improve deferred computation of checksums
When the SCTP, TCP, or UDP implementation send a packet, it does not
compute the corresponding checksum but defers that. The network layer
will determine whether the network interface selected for the packet
has the requested capability and computes the checksum in software,
if the selected network interface doesn't have the requested
capability.
Do this not only for packets being sent by the local SCTP, TCP,
and UDP stack, but also when forwarding packets. Furthermore, when
such packets are delivered to a local SCTP, TCP, or UDP stack, do not
compute or validate the checksum, since such packets never have been on
the wire.
This allows to support checksum offloading also in the case of local
virtual machines or jails.
Support for epair, vtnet, and tap interfaces will be added in
separate commits.
Reviewed by: kp, rgrimes, tuexen, manpages
[3 lines not shown]
mbuf.9: describe checksum offloading for SCTP
This describes the current status of the implementation.
While there, be a bit more precise on how long the checksum
computation is delayed.
Reviewed by: Timo Völker, bcr
Differential Revision: https://reviews.freebsd.org/D51590
(cherry picked from commit fe35f275ab0240cb5ed05484c943293a71aadb5f)
inpcb: Ignore SO_REUSEPORT_LB on connected sockets
While TCP disallows connect()ing a socket with SO_REUSEPORT_LB, UDP does
not. As a result, a connected UDP socket can be placed in the lbgroup
hash and thus receive datagrams from sources other than the connected
host.
Reported by: Amit Klein <amit.klein at mail.huji.ac.il>
Reported by: Omer Ben Simhon <omer.bensimhon at mail.huji.ac.il>
Reviewed by: glebius
Approved by: so
Security: FreeBSD-SA-25:09.netinet
Security: CVE-2025-24934
(cherry picked from commit 320ad3dec5ff1b37f6907a47961c18b9d77e6a53)
(cherry picked from commit e276759b368701a49e543c45d5d6ea08ed4fbc38)
vtnet: Do not compare boolean with integer
The type of variable promisc and allmulti was changed from int to bool
by commit [1].
[1] 7dce56596f36 Convert to if_foreach_llmaddr() KPI
MFC after: 3 days
(cherry picked from commit 80dfed11fc1c61ce9168db01dee263447619e859)
vtnet: improve control of transmit offloading
Keep the hwassist flags for transmit checksum offload and transmit
segment offload in sync with the enabled capabilities.
Reported by: Timo Völker
Reviewed by: Timo Völker
Differential Revision: https://reviews.freebsd.org/D52765
(cherry picked from commit f2575d56c8c9a8acad4a61a3586546dff4febce1)
vtnet.4: use transmit checksum offloading
Use transmit checksum offloading instead transmission checksum
offloading to be consistent with other man pages.
Reported by: Peter Lei
Sponsored by: Netflix, Inc.
(cherry picked from commit c7263f873ee9abb772f67b5536e2380a046e1b94)
vtnet: disable hardware TCP LRO by default
Hardware TCP LRO results in problems in settings with IP forwarding
being enabled. In case of nodes without IP forwarding, using
software LRO is also beneficial in general, since it can provide better
information about what was received on the wire.
Therefore, disable hardware TCP LRO by default.
By tuning the loader tunable, this can be changed.
PR: 263229
Reviewed by: Timo Völker
Differential Revision: https://reviews.freebsd.org/D52684
(cherry picked from commit 6e4b811009d63f33c59d51f28fd4a030ca90843e)
vtnet: improve interface capability handling
Enable the handling of the IFCAP_RXCSUM_IPV6 handling by handling
IFCAP_RXCSUM and IFCAP_RXCSUM_IPV6 as a pair. Also make clear, that
software and hardware LRO require receive checksum offload.
Reviewed by: Timo Völker
Differential Revision: https://reviews.freebsd.org/D52682
(cherry picked from commit eaf619fddcb21859311b895a0836da3171a01531)
vtnet: deprecate loader tunable fixup_needs_csum
If this tunable is enabled and vtnet receives a packet with
VIRTIO_NET_HDR_F_NEEDS_CSUM set, vtnet computes the TCP/UDP checksum
and writes it in the checksum field.
This was somewhat useful when vtnet pretended that such a packet has
a correct checksum and set the mbuf flag CSUM_DATA_VALID.
But this is not the case anymore.
Reviewed by: tuexen
Differential Revision: https://reviews.freebsd.org/D52546
(cherry picked from commit 5da388d93917f5fa74022960cc65452592f71539)
vtnet: Prefer "hardware" accounting for the multicast and total number of octets sent
When ALTQ is enabled, this driver does "hardware" accounting and soft
accounting at the same time. Prefer the "hardware" one to make the logic
simpler.
Reviewed by: zlei
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D44817
(cherry picked from commit 2a346c8993cbb92a321a7c25bd9ac4dcaae352d1)
vtnet: Do "hardware" accounting for the total number of received octets
While here, advertise the IFCAP_HWSTATS capability to avoid the net
stack from double counting it.
Co-authored-by: zlei
Reviewed by: zlei
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D44816
(cherry picked from commit a14d561e58529c9686a2efc47f4828ad82026e63)
vtnet: improve checksum offloading
When transmitting a packet over the vtnet interface, map the
csum flags CSUM_DATA_VALID | CSUM_PSEUDO_HDR to the virtio
flag VIRTIO_NET_HDR_F_DATA_VALID.
When receiving a packet over the virtio network channel, translate
the virtio flag VIRTIO_NET_HDR_F_NEEDS_CSUM not to CSUM_DATA_VALID |
CSUM_PSEUDO_HDR, but to CSUM_TCP, CSUM_TCP_IPV6, CSUM_UDP, or
CSUM_UDP_IPV6.
The second change fixes a series of issue related to checksum
offloading for if_vtnet.
While there, improve the stats counters to allow a detailed view
on what is going on in relation to checksum offloading.
PR: 165059
Reviewed by: tuexen, manpages
Differential Revision: https://reviews.freebsd.org/D51686
(cherry picked from commit 3008f30d2c2cabdd7e17f7fb922139da8681ffbd)
vtnet.4: improve existing descriptions and add missing ones
Improve several descriptions for loader tunables and add descriptions
of the statistics provided by read only sysctl-variables.
Reviewed by: bcr
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D51985
(cherry picked from commit ac87d70563f85d53575956c6fe40615b2e501c13)
