- dev - passt

[PATCH v2] conf: use a single buffer for print formatting in conf_print()
by Jon Maloy 15 Apr '26

15 Apr '26

The function conf_print() uses three different buffers as target for address print formatting. This is unnecessary, as a single buffer of length INANY_ADDRSTRLEN has sufficient space for all address types, IPv4, IPv6 and MAC. There is no risk for conflicts, since all formatting is followed by an immediate info() printout. To make our life easier in the following commits, we do this simplification here. Signed-off-by: Jon Maloy <jmaloy(a)redhat.com> --- v2: - Changed buffer length to INANY_ADDSTRLEN - Eliminated use of same buffer in same info() printout. --- conf.c | 48 ++++++++++++++++++++++++------------------------ 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/conf.c b/conf.c index dafac46..f13fef6 100644 --- a/conf.c +++ b/conf.c @@ -1136,11 +1136,12 @@ enum passt_modes conf_mode(int argc, char *argv[]) */ static void conf_print(const struct ctx *c) { - char buf4[INET_ADDRSTRLEN], buf6[INET6_ADDRSTRLEN]; - char bufmac[ETH_ADDRSTRLEN], ifn[IFNAMSIZ]; + char buf[INANY_ADDRSTRLEN]; int i; if (c->ifi4 > 0 || c->ifi6 > 0) { + char ifn[IFNAMSIZ]; + info("Template interface: %s%s%s%s%s", c->ifi4 > 0 ? if_indextoname(c->ifi4, ifn) : "", c->ifi4 > 0 ? " (IPv4)" : "", @@ -1158,28 +1159,27 @@ static void conf_print(const struct ctx *c) *c->ip6.ifname_out ? " (IPv6)" : ""); } - if (!IN4_IS_ADDR_UNSPECIFIED(&c->ip4.addr_out) || - !IN6_IS_ADDR_UNSPECIFIED(&c->ip6.addr_out)) { - info("Outbound address: %s%s%s", - IN4_IS_ADDR_UNSPECIFIED(&c->ip4.addr_out) ? "" : - inet_ntop(AF_INET, &c->ip4.addr_out, buf4, sizeof(buf4)), - (!IN4_IS_ADDR_UNSPECIFIED(&c->ip4.addr_out) && - !IN6_IS_ADDR_UNSPECIFIED(&c->ip6.addr_out)) ? ", " : "", - IN6_IS_ADDR_UNSPECIFIED(&c->ip6.addr_out) ? "" : - inet_ntop(AF_INET6, &c->ip6.addr_out, buf6, sizeof(buf6))); + if (!IN4_IS_ADDR_UNSPECIFIED(&c->ip4.addr_out)) { + inet_ntop(AF_INET, &c->ip4.addr_out, buf, sizeof(buf)); + info("Outbound IPv4 address: %s", buf); + } + + if (!IN6_IS_ADDR_UNSPECIFIED(&c->ip6.addr_out)) { + inet_ntop(AF_INET6, &c->ip6.addr_out, buf, sizeof(buf)); + info("Outbound IPv6 address: %s", buf); } if (c->mode == MODE_PASTA && !c->splice_only) info("Namespace interface: %s", c->pasta_ifn); info("MAC:"); - info(" host: %s", eth_ntop(c->our_tap_mac, bufmac, sizeof(bufmac))); + info(" host: %s", eth_ntop(c->our_tap_mac, buf, sizeof(buf))); if (c->ifi4) { if (!IN4_IS_ADDR_UNSPECIFIED(&c->ip4.map_host_loopback)) info(" NAT to host 127.0.0.1: %s", inet_ntop(AF_INET, &c->ip4.map_host_loopback, - buf4, sizeof(buf4))); + buf, sizeof(buf))); if (!c->no_dhcp) { uint32_t mask; @@ -1188,12 +1188,12 @@ static void conf_print(const struct ctx *c) info("DHCP:"); info(" assign: %s", - inet_ntop(AF_INET, &c->ip4.addr, buf4, sizeof(buf4))); + inet_ntop(AF_INET, &c->ip4.addr, buf, sizeof(buf))); info(" mask: %s", - inet_ntop(AF_INET, &mask, buf4, sizeof(buf4))); + inet_ntop(AF_INET, &mask, buf, sizeof(buf))); info(" router: %s", inet_ntop(AF_INET, &c->ip4.guest_gw, - buf4, sizeof(buf4))); + buf, sizeof(buf))); } for (i = 0; i < ARRAY_SIZE(c->ip4.dns); i++) { @@ -1201,8 +1201,8 @@ static void conf_print(const struct ctx *c) break; if (!i) info("DNS:"); - inet_ntop(AF_INET, &c->ip4.dns[i], buf4, sizeof(buf4)); - info(" %s", buf4); + inet_ntop(AF_INET, &c->ip4.dns[i], buf, sizeof(buf)); + info(" %s", buf); } for (i = 0; *c->dns_search[i].n; i++) { @@ -1216,7 +1216,7 @@ static void conf_print(const struct ctx *c) if (!IN6_IS_ADDR_UNSPECIFIED(&c->ip6.map_host_loopback)) info(" NAT to host ::1: %s", inet_ntop(AF_INET6, &c->ip6.map_host_loopback, - buf6, sizeof(buf6))); + buf, sizeof(buf))); if (!c->no_ndp && !c->no_dhcpv6) info("NDP/DHCPv6:"); @@ -1228,12 +1228,12 @@ static void conf_print(const struct ctx *c) goto dns6; info(" assign: %s", - inet_ntop(AF_INET6, &c->ip6.addr, buf6, sizeof(buf6))); + inet_ntop(AF_INET6, &c->ip6.addr, buf, sizeof(buf))); info(" router: %s", - inet_ntop(AF_INET6, &c->ip6.guest_gw, buf6, sizeof(buf6))); + inet_ntop(AF_INET6, &c->ip6.guest_gw, buf, sizeof(buf))); info(" our link-local: %s", inet_ntop(AF_INET6, &c->ip6.our_tap_ll, - buf6, sizeof(buf6))); + buf, sizeof(buf))); dns6: for (i = 0; i < ARRAY_SIZE(c->ip6.dns); i++) { @@ -1241,8 +1241,8 @@ dns6: break; if (!i) info("DNS:"); - inet_ntop(AF_INET6, &c->ip6.dns[i], buf6, sizeof(buf6)); - info(" %s", buf6); + inet_ntop(AF_INET6, &c->ip6.dns[i], buf, sizeof(buf)); + info(" %s", buf); } for (i = 0; *c->dns_search[i].n; i++) { -- 2.52.0

2 1

[PATCH v2 00/10] vhost-user: Preparatory series for multiple iovec entries per virtqueue element
by Laurent Vivier 15 Apr '26

15 Apr '26

Currently, the vhost-user path assumes each virtqueue element contains exactly one iovec entry covering the entire frame. This assumption breaks as some virtio-net drivers (notably iPXE) provide descriptors where the vnet header and the frame payload are in separate buffers, resulting in two iovec entries per virtqueue element. This series refactors the vhost-user data path so that frame lengths, header sizes, and padding are tracked and passed explicitly rather than being derived from iovec sizes. This decoupling is a prerequisite for correctly handling padding of multi-buffer frames. The changes in this series can be split in 3 groups: - New iov helpers (patches 1-2): iov_memset() and iov_memcopy() operate across iovec boundaries. These are needed by the final patch to pad and copy frame data when a frame spans multiple iovec entries. - Structural refactoring (patches 3-5): Move vnethdr setup into vu_flush(), separate virtqueue management from socket I/O in the UDP path, and pass iov arrays explicitly instead of using file-scoped state. These changes make it possible to pass explicit frame lengths through the stack, which is required to pad frames independently of iovec layout. - Explicit length passing throughout the stack (patches 6-10): Thread explicit L4, L2, frame, and data lengths through checksum, pcap, vu_flush(), and tcp_fill_headers(), replacing lengths that were previously derived from iovec sizes. With lengths tracked explicitly, the final patch can centralise Ethernet frame padding into vu_collect() and a new vu_pad() helper that correctly pads frames spanning multiple iovec entries. v2: - Rename iov_memcopy() to iov_memcpy() and use clearer parameter names - Use clearer code in pcap_frame() - Add braces around bodies in pcap.c and tcp_vu.c for style consistency - Extract l2len variable in tap_add_packet() and tcp_vu_send_flag() to avoid repeating the same expression - Fix indentation alignment of iov_skip_bytes() arguments in tcp_vu_c - Introduce fill_size variable in vu_flush() - Reposition comment for ETH_ZLEN in vu_collect() Laurent Vivier (10): iov: Introduce iov_memset() iov: Add iov_memcpy() to copy data between iovec arrays vu_common: Move vnethdr setup into vu_flush() udp_vu: Move virtqueue management from udp_vu_sock_recv() to its caller udp_vu: Pass iov explicitly to helpers instead of using file-scoped array checksum: Pass explicit L4 length to checksum functions pcap: Pass explicit L2 length to pcap_iov() vu_common: Pass explicit frame length to vu_flush() tcp: Pass explicit data length to tcp_fill_headers() vhost-user: Centralise Ethernet frame padding in vu_collect() and vu_pad() checksum.c | 35 ++++++----- checksum.h | 6 +- iov.c | 78 ++++++++++++++++++++++++ iov.h | 5 ++ pcap.c | 41 ++++++++++--- pcap.h | 2 +- tap.c | 7 ++- tcp.c | 14 +++-- tcp_buf.c | 3 +- tcp_internal.h | 2 +- tcp_vu.c | 66 ++++++++++---------- udp.c | 5 +- udp_vu.c | 162 ++++++++++++++++++++++++++----------------------- vu_common.c | 58 ++++++++++-------- vu_common.h | 5 +- 15 files changed, 311 insertions(+), 178 deletions(-) -- 2.53.0

2 20

[PATCH v7 0/3] vhost-user,udp: Handle multiple iovec entries per virtqueue element
by Laurent Vivier 13 Apr '26

13 Apr '26

Some virtio-net drivers (notably iPXE) provide descriptors where the vnet header and the frame payload are in separate buffers, resulting in two iovec entries per virtqueue element. Currently, the RX (host to guest) path assumes a single iovec per element, which triggers: ASSERTION FAILED in virtqueue_map_desc (virtio.c:403): num_sg < max_num_sg This series reworks the UDP vhost-user receive path to support multiple iovec entries per element, fixing the iPXE crash. This series only addresses the UDP path. TCP vhost-user will be updated to use multi-iov elements in a subsequent series. Based-on: 20260403163811.3209635-1-lvivier(a)redhat.com v7: - In udp_vu_sock_to_tap(), introduce iov_still_needed variable - Fix iov_tail @data doc comments in udp_vu_prepare()/udp_vu_csum() - Don't rewrap the virtio checksum comment in udp_update_hdr6() - Add NULL check for uh in udp_vu_csum() v6: - Rebased on top of [PATCH 00/10] vhost-user: Preparatory series for multiple iovec entries per virtqueue element v5: - This version doesn't change the padding system regarding v4, it's a complex task that will be addressed in another version - reorder patches and add new patches - remove IOV_PUT_HEADER()/with_header() and introduce IOV_PUSH_HEADER() - don't use the iov_tail to provide the headers to the functions - move vu_set_vnethdr() to vu_flush(), extract vu_queue_notify() - move vu_flush() inside loop in tcp_vu_data_from_sock() to flush data by frame and not by full data length v4: - rebase - replace ASSERT() by assert() v3: - include the series "Decouple iovec management from virtqueues elements" - because of this series, drop: "vu_common: Accept explicit iovec counts in vu_set_element()" "vu_common: Accept explicit iovec count per element in vu_init_elem()" "vu_common: Prepare to use multibuffer with guest RX" "vhost-user,udp: Use 2 iovec entries per element" - drop "vu_common: Pass iov_tail to vu_set_vnethdr()" as the specs insures a buffer is big enough to contain vnet header - introduce "with_header()" and merge "udp: Pass iov_tail to udp_update_hdr4()/udp_update_hdr6()" and "udp_vu: Use iov_tail in udp_vu_prepare()" to use it v2: - add iov_truncate(), iov_memset() - remove iov_tail_truncate() and iov_tail_zero_end() - manage 802.3 minimum frame size Laurent Vivier (3): udp_vu: Allow virtqueue elements with multiple iovec entries iov: Introduce IOV_PUSH_HEADER() macro udp: Pass iov_tail to udp_update_hdr4()/udp_update_hdr6() iov.c | 22 ++++++++++ iov.h | 11 +++++ udp.c | 65 +++++++++++++++------------- udp_internal.h | 4 +- udp_vu.c | 113 ++++++++++++++++++++++++++----------------------- 5 files changed, 131 insertions(+), 84 deletions(-) -- 2.53.0

2 6

[PATCH 00/18] Rework forwarding option parsing
by David Gibson 09 Apr '26

09 Apr '26

This series makes a number of significant reworks to how we process forwarding options (-t, -u, -T and -U) in passt & pasta. This is largely motivated by moving towards being able to share this code with a configuration update tool. However, along the way it also enables some forwarding configurations that were technically possible with the forwarding table but couldn't be specified on the command line, in particular bug 180. There is still a bunch of work needed to make the parsing code truly shareable with pesto, but this is a solid start. David Gibson (18): conf: Split parsing of port specifiers from the rest of -[tuTU] parsing conf: Simplify handling of default forwarding mode conf: Move first pass handling of -[TU] next to handling of -[tu] doc: Consolidate -[tu] option descriptions for passt and pasta conf: Permit -[tTuU] all in pasta mode fwd: Better split forwarding rule specification from associated sockets fwd_rule: Move forwarding rule formatting conf: Pass protocol explicitly to conf_ports_range_except() fwd: Split rule building from rule adding fwd_rule: Move rule conflict checking from fwd_rule_add() to caller fwd: Improve error handling in fwd_rule_add() conf: Don't be strict about exclusivity of forwarding mode conf: Rework stepping through chunks of port specifiers conf: Rework checking for garbage after a range conf: Move "all" handling to port specifier conf: Allow user-specified auto-scanned port forwarding ranges conf: Move SO_BINDTODEVICE workaround to conf_ports() conf: Don't pass raw commandline argument to conf_ports_spec() Makefile | 10 +- conf.c | 541 ++++++++++++++++++++++++++--------------------------- fwd.c | 190 ++++++------------- fwd.h | 21 +-- fwd_rule.c | 132 +++++++++++++ fwd_rule.h | 15 ++ passt.1 | 214 +++++++-------------- 7 files changed, 542 insertions(+), 581 deletions(-) create mode 100644 fwd_rule.c -- 2.53.0

2 41

[PATCH 02/18] conf: Simplify handling of default forwarding mode
by David Gibson 08 Apr '26

08 Apr '26

For passt, the default forwarding mode is "none", which falls out naturally from the other handling: if we don't get any options, we get empty forwarding tables, which corresponds to "none" behaviour. However, for pasta the default is "auto". This is handled a bit oddly: in conf_ports() we set the mode variable, but don't set up the rules we need for "auto" mode. Instead we want until nearly the end of conf() and if the mode is FWD_MODE_AUTO or unset, we make conf_ports_range_except() calls to set up the "auto" rules. Simplify this a bit, by creating the rules within conf_ports() itself when we parse -[tuTU] auto. For the case of no forwarding options we call into conf_ports() itself with synthetic arguments. As well as making the code a little shorter, this makes it more obvious that giving no arguments really is equivalent to -[tuTU] auto. Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au> --- conf.c | 54 ++++++++++++++++++++++-------------------------------- 1 file changed, 22 insertions(+), 32 deletions(-) diff --git a/conf.c b/conf.c index c515480b..7d718f91 100644 --- a/conf.c +++ b/conf.c @@ -345,6 +345,10 @@ static void conf_ports(const struct ctx *c, char optname, const char *optarg, die("'auto' port forwarding is only allowed for pasta"); *mode = FWD_MODE_AUTO; + + conf_ports_range_except(c, optname, optarg, fwd, NULL, NULL, + 1, NUM_PORTS - 1, NULL, 1, FWD_SCAN); + return; } @@ -1576,7 +1580,6 @@ void conf(struct ctx *c, int argc, char **argv) enum fwd_mode udp_out_mode = FWD_MODE_UNSET; enum fwd_mode tcp_in_mode = FWD_MODE_UNSET; enum fwd_mode udp_in_mode = FWD_MODE_UNSET; - enum fwd_mode fwd_default = FWD_MODE_NONE; bool v4_only = false, v6_only = false; unsigned dns4_idx = 0, dns6_idx = 0; unsigned long max_mtu = IP_MAX_MTU; @@ -1593,10 +1596,8 @@ void conf(struct ctx *c, int argc, char **argv) gid_t gid; - if (c->mode == MODE_PASTA) { + if (c->mode == MODE_PASTA) c->no_dhcp_dns = c->no_dhcp_dns_search = 1; - fwd_default = FWD_MODE_AUTO; - } if (tap_l2_max_len(c) - ETH_HLEN < max_mtu) max_mtu = tap_l2_max_len(c) - ETH_HLEN; @@ -2244,34 +2245,23 @@ void conf(struct ctx *c, int argc, char **argv) if_indextoname(c->ifi6, c->pasta_ifn); } - if (!tcp_in_mode) - tcp_in_mode = fwd_default; - if (!tcp_out_mode) - tcp_out_mode = fwd_default; - if (!udp_in_mode) - udp_in_mode = fwd_default; - if (!udp_out_mode) - udp_out_mode = fwd_default; - - if (tcp_in_mode == FWD_MODE_AUTO) { - conf_ports_range_except(c, 't', "auto", c->fwd[PIF_HOST], - NULL, NULL, 1, NUM_PORTS - 1, NULL, 1, - FWD_SCAN); - } - if (tcp_out_mode == FWD_MODE_AUTO) { - conf_ports_range_except(c, 'T', "auto", c->fwd[PIF_SPLICE], - NULL, "lo", 1, NUM_PORTS - 1, NULL, 1, - FWD_SCAN); - } - if (udp_in_mode == FWD_MODE_AUTO) { - conf_ports_range_except(c, 'u', "auto", c->fwd[PIF_HOST], - NULL, NULL, 1, NUM_PORTS - 1, NULL, 1, - FWD_SCAN); - } - if (udp_out_mode == FWD_MODE_AUTO) { - conf_ports_range_except(c, 'U', "auto", c->fwd[PIF_SPLICE], - NULL, "lo", 1, NUM_PORTS - 1, NULL, 1, - FWD_SCAN); + if (c->mode == MODE_PASTA) { + if (!tcp_in_mode) { + conf_ports(c, 't', "auto", + c->fwd[PIF_HOST], &tcp_in_mode); + } + if (!tcp_out_mode) { + conf_ports(c, 'T', "auto", + c->fwd[PIF_SPLICE], &tcp_out_mode); + } + if (!udp_in_mode) { + conf_ports(c, 'u', "auto", + c->fwd[PIF_HOST], &udp_in_mode); + } + if (!udp_out_mode) { + conf_ports(c, 'U', "auto", + c->fwd[PIF_SPLICE], &udp_out_mode); + } } if (!c->quiet) -- 2.53.0

2 2

Re: [PATCH] SELinux: Dontaudit access to dri devices
by Stefano Brivio 07 Apr '26

07 Apr '26

On Tue, 7 Apr 2026 10:27:04 +0200 Johannes Segitz <jsegitz(a)suse.de> wrote: > On Thu, Apr 02, 2026 at 03:36:58PM +0200, Paul Holzinger wrote: > > I did a quick spot check in Podman and found a few places where a fd might > > be leaked: https://github.com/containers/podman/pull/28434 > > > > That said I do not think any of these would explain an open /dev/dri path. > > I build podman with the change (and passt with the broader fd closing > logic) and asked the reporter to test them. The denial is still shown with > this unfortunately Johannes, thanks for reporting back. Paul, I was wondering: would there be a way to do something equivalent to that close_range() directly in Podman, before it starts pasta? I think it's a separate thread (or even a forked process) starting it, but I haven't really checked. -- Stefano

2 1

[PATCH] SELinux: Dontaudit access to dri devices
by Johannes Segitz 07 Apr '26

07 Apr '26

Currently podman can pass a FD to a DRI device to pasta, leading to AVCs like this: avc: denied { read write } comm="pasta" path="/dev/dri/renderD128" scontext=unconfined_u:unconfined_r:pasta_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dri_device_t:s0 tclass=chr_file These are harmless, so dontaudit them Signed-off-by: Johannes Segitz <jsegitz(a)suse.de> --- contrib/selinux/pasta.te | 2 ++ 1 file changed, 2 insertions(+) diff --git a/contrib/selinux/pasta.te b/contrib/selinux/pasta.te index fb51416..4bc7dcc 100644 --- a/contrib/selinux/pasta.te +++ b/contrib/selinux/pasta.te @@ -262,3 +262,5 @@ if (pasta_bind_all_ports) { allow pasta_t port_type:tcp_socket { accept getopt name_bind name_connect }; allow pasta_t port_type:udp_socket { accept getopt name_bind }; } + +dev_dontaudit_rw_dri(pasta_t) -- 2.53.0

3 9

[PATCH 0/2] vhost-user, dhcp: Fix iPXE network boot over vhost-user
by Laurent Vivier 07 Apr '26

07 Apr '26

iPXE network boot over vhost-user was broken because passt unconditionally skipped TCP/UDP checksum computation, relying on VIRTIO_NET_HDR_F_DATA_VALID to tell the guest the checksums were valid. Linux guests happened to work because their virtio-net driver honours DATA_VALID regardless of feature negotiation, but iPXE verifies checksums strictly and never negotiates VIRTIO_NET_F_GUEST_CSUM. This series handles correctly VIRTIO_NET_F_GUEST_CSUM feature to fix that and adds a minimal --dhcp-boot option that populates the BOOTP/DHCP 'file' field, providing just enough for testing iPXE UDP and TCP support. This can be tested as following: - Create an ipxe file configuration cat > boot-alpine.ipxe <<EOF kernel http://dl-cdn.alpinelinux.org/alpine/v3.23/releases/x86_64/netboot/vmlinuz-… console=ttyS0,115200 alpine_repo=http://dl-cdn.alpinelinux.org/alpine/v3.23/main modloop=http://dl-cdn.alpinelinux.org/alpine/v3.23/releases/x86_64/netboot/… initrd http://dl-cdn.alpinelinux.org/alpine/v3.23/releases/x86_64/netboot/initramf… boot EOF - Start a web server in the same directory as boot-alpine.ipxe python -m http.server 8080 - Start passt: ./passt -f --dhcp-boot http://<host ip address>:8080/boot-alpine.ipxe --vhost-user - Start QEMU without boot disk but with passt as networking backend Based-on: 20260401215508.2149752-1-lvivier(a)redhat.com Laurent Vivier (2): vhost_user: Offer VIRTIO_NET_F_GUEST_CSUM dhcp: Add --dhcp-boot option to set boot filename in DHCP replies conf.c | 10 ++++++++++ dhcp.c | 5 ++++- passt.1 | 6 ++++++ passt.h | 1 + tcp_vu.c | 8 ++++++-- udp_vu.c | 7 ++++--- vhost_user.c | 1 + 7 files changed, 32 insertions(+), 6 deletions(-) -- 2.53.0

2 4

[PATCH v2] tap, tcp, udp: Use rate-limited logging
by Anshu Kumari 07 Apr '26

07 Apr '26

Now that rate-limited logging macros are available, promote several debug messages to higher severity levels. These messages were previously kept at debug to prevent guests from flooding host logs, but with rate limiting they can safely be made visible in normal operation. In tap.c, refactor tap4_is_fragment() to use warn_ratelimit() instead of its ad-hoc rate limiting, and promote the guest MAC address change message to info level. In tcp.c, promote the invalid TCP SYN endpoint message to warn level. In udp.c and udp_flow.c, promote flow allocation failures and dropped datagram messages to warn level, and rate-limit the unrecoverable socket error message. Link: https://bugs.passt.top/show_bug.cgi?id=134 Signed-off-by: Anshu Kumari <anskuma(a)redhat.com> --- v2: - removed #define FRAGMENT_MSG_RATE - fixed the indentation for "Invalid endpoint in TCP SYN" log. - Inside udp.c - David: should this be changed to warn_ratelimit? I am not sure about it debug("%s error on UDP socket %i: %s", str_ee_origin(ee), s, strerror_(ee->ee_errno)); --- tap.c | 15 ++++----------- tcp.c | 6 +++--- udp.c | 6 +++--- udp_flow.c | 4 ++-- 4 files changed, 12 insertions(+), 19 deletions(-) diff --git a/tap.c b/tap.c index 1049e02..b7270d9 100644 --- a/tap.c +++ b/tap.c @@ -99,7 +99,6 @@ static PACKET_POOL_NOINIT(pool_tap4, TAP_MSGS_IP4); static PACKET_POOL_NOINIT(pool_tap6, TAP_MSGS_IP6); #define TAP_SEQS 128 /* Different L4 tuples in one batch */ -#define FRAGMENT_MSG_RATE 10 /* # seconds between fragment warnings */ /** * tap_l2_max_len() - Maximum frame size (including L2 header) for current mode @@ -686,17 +685,11 @@ static bool tap4_is_fragment(const struct iphdr *iph, const struct timespec *now) { if (ntohs(iph->frag_off) & ~IP_DF) { - /* Ratelimit messages */ - static time_t last_message; static unsigned num_dropped; num_dropped++; - if (now->tv_sec - last_message > FRAGMENT_MSG_RATE) { - warn("Can't process IPv4 fragments (%u dropped)", - num_dropped); - last_message = now->tv_sec; - num_dropped = 0; - } + warn_ratelimit(now, "Can't process IPv4 fragments (%u dropped)", + num_dropped); return true; } return false; @@ -1115,8 +1108,8 @@ void tap_add_packet(struct ctx *c, struct iov_tail *data, char bufmac[ETH_ADDRSTRLEN]; memcpy(c->guest_mac, eh->h_source, ETH_ALEN); - debug("New guest MAC address observed: %s", - eth_ntop(c->guest_mac, bufmac, sizeof(bufmac))); + info_ratelimit(now, "New guest MAC address observed: %s", + eth_ntop(c->guest_mac, bufmac, sizeof(bufmac))); proto_update_l2_buf(c->guest_mac); } diff --git a/tcp.c b/tcp.c index 8ea9be8..964cfc2 100644 --- a/tcp.c +++ b/tcp.c @@ -1688,9 +1688,9 @@ static void tcp_conn_from_tap(const struct ctx *c, sa_family_t af, !inany_is_unicast(&ini->oaddr) || ini->oport == 0) { char sstr[INANY_ADDRSTRLEN], dstr[INANY_ADDRSTRLEN]; - debug("Invalid endpoint in TCP SYN: %s:%hu -> %s:%hu", - inany_ntop(&ini->eaddr, sstr, sizeof(sstr)), ini->eport, - inany_ntop(&ini->oaddr, dstr, sizeof(dstr)), ini->oport); + warn_ratelimit(now, "Invalid endpoint in TCP SYN: %s:%hu -> %s:%hu", + inany_ntop(&ini->eaddr, sstr, sizeof(sstr)), ini->eport, + inany_ntop(&ini->oaddr, dstr, sizeof(dstr)), ini->oport); goto cancel; } diff --git a/udp.c b/udp.c index 1fc5a42..1ef5e7a 100644 --- a/udp.c +++ b/udp.c @@ -871,7 +871,7 @@ void udp_sock_fwd(const struct ctx *c, int s, int rule_hint, /* Clear errors & carry on */ if (udp_sock_errs(c, s, FLOW_SIDX_NONE, frompif, port) < 0) { - err( + err_ratelimit(now, "UDP: Unrecoverable error on listening socket: (%s port %hu)", pif_name(frompif), port); /* FIXME: what now? close/re-open socket? */ @@ -898,7 +898,7 @@ void udp_sock_fwd(const struct ctx *c, int s, int rule_hint, pif_name(frompif), pif_name(topif)); discard = true; } else { - debug("Discarding datagram without flow"); + warn_ratelimit(now, "Discarding datagram without flow"); discard = true; } @@ -1042,7 +1042,7 @@ int udp_tap_handler(const struct ctx *c, uint8_t pif, if (!(uflow = udp_at_sidx(tosidx))) { char sstr[INET6_ADDRSTRLEN], dstr[INET6_ADDRSTRLEN]; - debug("Dropping datagram with no flow %s %s:%hu -> %s:%hu", + warn_ratelimit(now, "Dropping datagram with no flow %s %s:%hu -> %s:%hu", pif_name(pif), inet_ntop(af, saddr, sstr, sizeof(sstr)), src, inet_ntop(af, daddr, dstr, sizeof(dstr)), dst); diff --git a/udp_flow.c b/udp_flow.c index 7e2453e..9343b4b 100644 --- a/udp_flow.c +++ b/udp_flow.c @@ -235,7 +235,7 @@ flow_sidx_t udp_flow_from_sock(const struct ctx *c, uint8_t pif, if (!(flow = flow_alloc())) { char sastr[SOCKADDR_STRLEN]; - debug("Couldn't allocate flow for UDP datagram from %s %s", + warn_ratelimit(now, "Couldn't allocate flow for UDP datagram from %s %s", pif_name(pif), sockaddr_ntop(s_in, sastr, sizeof(sastr))); return FLOW_SIDX_NONE; } @@ -292,7 +292,7 @@ flow_sidx_t udp_flow_from_tap(const struct ctx *c, if (!(flow = flow_alloc())) { char sstr[INET6_ADDRSTRLEN], dstr[INET6_ADDRSTRLEN]; - debug("Couldn't allocate flow for UDP datagram from %s %s:%hu -> %s:%hu", + warn_ratelimit(now, "Couldn't allocate flow for UDP datagram from %s %s:%hu -> %s:%hu", pif_name(pif), inet_ntop(af, saddr, sstr, sizeof(sstr)), srcport, inet_ntop(af, daddr, dstr, sizeof(dstr)), dstport); -- 2.53.0

3 2

[PATCH 03/18] conf: Move first pass handling of -[TU] next to handling of -[tu]
by David Gibson 07 Apr '26

07 Apr '26

The forwarding options -[tTuU] can't be fully handled in our first pass over the command line options, they need to wait until the second, once we know more about the interface configuration. However, we do need stub handling, so they don't cause an error. For historical reasons the -[TU] options are handled a fair way apart from the -[tu] options. Move them next to each other for clarity. Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au> --- conf.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/conf.c b/conf.c index 7d718f91..f3b36bb6 100644 --- a/conf.c +++ b/conf.c @@ -2024,6 +2024,12 @@ void conf(struct ctx *c, int argc, char **argv) c->one_off = true; break; + case 'T': + case 'U': + if (c->mode != MODE_PASTA) + die("-%c is for pasta mode only", name); + + /* fall through */ case 't': case 'u': /* Handle these later, once addresses are configured */ @@ -2064,13 +2070,6 @@ void conf(struct ctx *c, int argc, char **argv) die("Cannot use DNS address %s", optarg); } break; - case 'T': - case 'U': - if (c->mode != MODE_PASTA) - die("-%c is for pasta mode only", name); - - /* Handle properly later, once addresses are configured */ - break; case 'h': usage(argv[0], stdout, EXIT_SUCCESS); break; -- 2.53.0

1 0