From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Plj1JhV3; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 2734B5A0262 for ; Wed, 01 Apr 2026 20:29:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1775068157; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=zXKU9qYM4/2wC9juOsUSMt+ylRMv3k/ShDZG8g2qRN0=; b=Plj1JhV3FRrag/gijSK+eehLpq2ZZ+MbGD4Rx4/3tpnm4aDMA+cgny1vkeEsW30aCFnxS7 po6+ffJmZ8vsUp4ooA7g3Z5UaSb0EG2nuWpwPANe8gPY1ju6HyUg+/bCtunrN7yp26FIN2 VY86jjioaQ+xMrmEROsuUDRZPJHsF8I= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-196-gxi3_TdUON6htZBSsMfO8g-1; Wed, 01 Apr 2026 14:29:15 -0400 X-MC-Unique: gxi3_TdUON6htZBSsMfO8g-1 X-Mimecast-MFC-AGG-ID: gxi3_TdUON6htZBSsMfO8g_1775068155 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id ED0E219560B4; Wed, 1 Apr 2026 18:29:14 +0000 (UTC) Received: from anskuma-thinkpadp1gen7.bengluru.csb (unknown [10.74.80.30]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id D200419560AB; Wed, 1 Apr 2026 18:29:11 +0000 (UTC) From: Anshu Kumari To: anskuma@redhat.com, sbrivio@redhat.com, passt-dev@passt.top Subject: [PATCH v1 2/2] tap, tcp, udp: Use rate-limited logging Date: Wed, 1 Apr 2026 23:59:10 +0530 Message-ID: <20260401182910.669164-1-anskuma@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: _rKKpFwiUMip6f2mPavexRl46lBTqXAIfxvNaZ43Sdw_1775068155 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true Message-ID-Hash: RCOT3FRNJP4BO2EPREO5IPLRPVJSRO3U X-Message-ID-Hash: RCOT3FRNJP4BO2EPREO5IPLRPVJSRO3U X-MailFrom: anskuma@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: lvivier@redhat.com, david@gibson.dropbear.id.au X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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 --- - 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 | 14 ++++---------- tcp.c | 2 +- udp.c | 6 +++--- udp_flow.c | 4 ++-- 4 files changed, 10 insertions(+), 16 deletions(-) diff --git a/tap.c b/tap.c index 1049e02..f569b61 100644 --- a/tap.c +++ b/tap.c @@ -686,17 +686,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 +1109,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..3d3b80d 100644 --- a/tcp.c +++ b/tcp.c @@ -1688,7 +1688,7 @@ 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", + 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