FreeBSD source tree http://cgit.freebsd.org/src/atom?h=main 2026-08-07T16:30:24Z 2026-08-07T16:30:24Z Mark Johnston markj@FreeBSD.org 2026-08-07T14:46:52Z urn:sha1:800d5b7a8a4f5665ced0453e090f8d563366bd47 if_initname() requires the caller to ensure that the lifetime of the interface's name buffer contains that of the ifnet itself. netmap_vi_create() wasn't respecting that; we were instead passing the stack-allocated buffer provided by the ioctl handler. While here, add a check to avoid assuming that the caller-provided buffer is nul-terminated. Reported by: syzkaller Reviewed by: vmaffione MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D58676 2024-10-14T13:33:33Z Mark Johnston markj@FreeBSD.org 2024-10-14T13:30:09Z urn:sha1:1bae9dc584272dd75dc4e04cb5d73be0e9fb562a Each netmap adapter associated with a physical adapter is attached to a netmap memory pool. contigmalloc() is used to allocate physically contiguous memory for the pool, but ideally we would ensure that all such memory is allocated from the NUMA domain local to the adapter. Augment netmap's memory pools with a NUMA domain ID, similar to how IOMMU groups are handled in the Linux port. That is, when attaching to a physical adapter, ensure that the associated memory pools are local to the adapter's associated memory domain, creating new pools as needed. Some types of ifnets do not have any defined NUMA affinity; in this case the domain ID in question is the sentinel value -1. Add a sysctl, dev.netmap.port_numa_affinity, which can be used to enable the new behaviour. Keep it disabled by now to avoid surprises in case netmap applications are relying on zero-copy optimizations to forward packets between ports belonging to different NUMA domains. Reviewed by: vmaffione MFC after: 2 weeks Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D46666 2024-03-26T09:55:55Z Tom Jones thj@FreeBSD.org 2024-03-26T09:52:07Z urn:sha1:73fdbfb911215795c55c89870ebc5d9197bf2a23 netmap_generic keeps a pool of mbufs for handling transfers, these mbufs have an external buffer attached to them. If some cases other parts of the network stack can chain these mbufs, when this happens the normal pool destructor function can end up free'ing the pool mbufs twice: - A first time if a pool mbuf has been chained with another mbuf when its chain is freed - A second time when its entry in the pool is freed Additionally, if other parts of the stack demote a pool mbuf its interface reference will be cleared. In this case we deference a NULL pointer when trying to free the mbuf through the destructor. Store a reference to the adapter in ext_arg1 with the destructor callback so we can find the correct adapter when free'ing a pool mbuf. This change enables using netmap with epair interfaces. Reviewed By: vmaffione MFC after: 1 week Relnotes: yes Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D44371 2023-12-27T15:13:29Z Mark Johnston markj@FreeBSD.org 2023-12-27T15:13:29Z urn:sha1:99efa2c88d93c6272a8f54b18d18d0fd9d60f137 The CSB_WRITE() and _READ() macros respectively write to and read from userspace memory and so can in principle fault. However, we do not check for errors and will proceed blindly if they fail. Add assertions to verify that they do not. This is in preparation for annotating copyin() and related functions with __result_use_check. Reviewed by: vmaffione MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D43200 2023-08-16T17:54:18Z Warner Losh imp@FreeBSD.org 2023-08-16T17:54:18Z urn:sha1:2ff63af9b88c7413b7d71715b5532625752a248e Remove /^\s*\*+\s*\$FreeBSD\$.*$\n/ 2023-05-12T16:44:03Z Warner Losh imp@FreeBSD.org 2023-05-10T15:40:58Z urn:sha1:4d846d260e2b9a3d4d0a701462568268cbfe7a5b The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix 2023-04-05T16:12:30Z Mark Johnston markj@FreeBSD.org 2023-04-05T16:12:30Z urn:sha1:ce12afaa6fff46c9027eb6b2bd515a4e46ecefc9 In emulated mode, the FreeBSD netmap port attempts to perform zero-copy transmission. This works as follows: the kernel ring is populated with mbuf headers to which netmap buffers are attached. When transmitting, the mbuf refcount is initialized to 2, and when the counter value has been decremented to 1 netmap infers that the driver has freed the mbuf and thus transmission is complete. This scheme does not generalize to the situation where netmap is attaching to a software interface which may transmit packets among multiple "queues", as is the case with bridge or lagg interfaces. In that case, we would be relying on backing hardware drivers to free transmitted mbufs promptly, but this isn't guaranteed; a driver may reasonably defer freeing a small number of transmitted buffers indefinitely. If such a buffer ends up at the tail of a netmap transmit ring, further transmits can end up blocked indefinitely. Fix the problem by removing the zero-copy scheme (which is also not implemented in the Linux port of netmap). Instead, the kernel ring is populated with regular mbuf clusters into which netmap buffers are copied by nm_os_generic_xmit_frame(). The refcounting scheme is preserved, and this lets us avoid allocating a fresh cluster per transmitted packet in the common case. If the transmit ring is full, a callout is used to free the "stuck" mbuf, avoiding the queue deadlock described above. Furthermore, when recycling mbuf clusters, be sure to fully reinitialize the mbuf header instead of simply re-setting M_PKTHDR. Some software interfaces, like if_vlan, may set fields in the header which should be reset before the mbuf is reused. Reviewed by: vmaffione MFC after: 1 month Sponsored by: Zenarmor Sponsored by: OPNsense Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D38065 2023-03-14T22:04:23Z Vincenzo Maffione vmaffione@FreeBSD.org 2023-03-14T21:59:23Z urn:sha1:6c9fe357435db6408ec6b01221b9ff9e7e9b0ff1 The save_if_input function pointer was meant to save the previous value of ifp->if_input before replacing it with the emulated adapter hook. However, the same pointer value is already stored in the if_input field of the netmap_adapter struct, to be used for host TX ring processing. Reuse the netmap_adapter if_input field to simplify the code and save some space. MFC after: 14 days 2023-03-11T17:19:40Z Vincenzo Maffione vmaffione@FreeBSD.org 2023-03-11T17:19:01Z urn:sha1:22bf2a479f68d5a5b8c002a9103d95f3c7547067 MFC after: 7 days 2023-02-14T15:21:19Z Justin Hibbits jhibbits@FreeBSD.org 2023-01-12T18:38:37Z urn:sha1:e330262f34fc179ce920c16bb28ba8a1c4a73aff Reviewed by: vmaffione, zlei Sponsored by: Juniper Networks, Inc. Differential Revision: https://reviews.freebsd.org/D37814