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=VFNS5U2y; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id E56745A0265 for ; Mon, 06 Apr 2026 10:12:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1775463172; 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: in-reply-to:in-reply-to:references:references; bh=NOza26sfG4sdNo1gOdBs95Dg3BdxJNi6l1NJ7IYWvq8=; b=VFNS5U2yvYQrGJLC9BCEfdrMjJCmIYmdLNUI2ob7vZX+iq59fBpyraURiO7uB1OjqalDli N6VoQ+bfVGdZLv+dmmXWKlY/kCpNNBn3QIlz26dm3wGpdx3pLWyOMFqtzYhNo9mcH4Lx2u Psz5E5VMI/AWTngvBMF+2ZmsNxB8uUk= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-677-V62EzymINgSWmC1Yoyxbmg-1; Mon, 06 Apr 2026 04:12:51 -0400 X-MC-Unique: V62EzymINgSWmC1Yoyxbmg-1 X-Mimecast-MFC-AGG-ID: V62EzymINgSWmC1Yoyxbmg_1775463170 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-488a9ed3c1eso7359225e9.1 for ; Mon, 06 Apr 2026 01:12:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775463170; x=1776067970; h=date:content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NOza26sfG4sdNo1gOdBs95Dg3BdxJNi6l1NJ7IYWvq8=; b=WqOILSGClfHNLJAZLzaC54V3uzvfs79o2hmDtYyxgj1RBgGUa9ZkJvwCmebBdfHrca Cy38EXHUpGK0Ga7PzSIl8U4tvdxREwRi+pOL6lHlp5swMAGo+2Z5toG4C321ETrlb3aI 2/+NqqoFVKddISk7nQ0ytF9B7smvMxbxQpvU87w48ph2SlLSTXIJAw2I/kMflvR5BQrB k/2o4egUd/gJaPVmuvF57n97lE6JSXi0C5U+0gi68EEO/cCheOpqUj+wGqZFEb40hpSN IhiyybKTpZuHGDve7VxflPKpcKvZtTEdHDsWKvKqmzYGwPLvjCBG+nWYAtMSuYnvIee5 X/Bg== X-Gm-Message-State: AOJu0YxZFBJPEiT3m1Z5B7VCIqKlMhoMRhRq4lquImNxJMZ01PR5wYlZ sPBiJtEgtNeACwhZ9Rr23Teb7jzqHYgymIUbCZgxONkJQUvHkxhJvyVbbSRgxv8AvD03LHelJtI HHI8J3Kub/Y+byS5F4hhts/wRe11tRgh22EosHMyTWA9vdcuqvey+dQ== X-Gm-Gg: AeBDietON3azUPeaUHaQFajbBuylnlVFpibzUR0DoAl7jWU5iCkhS9HdQCOD8f8hzB7 FimdhFQqdO4kJY+KVrVAbkBwVgaE7lQSYO/sYlS+Dm4zt9PF8egXdDA2/q5+jxAzx+ajM/51phn f++trJR1f2uIlmf0B9mDsSX6Y5Gcq0E4S1M8xcVKkHAtE6fWuJ7tWyZVAUoKvuRKKFBxxpdRVcb y/v4TKPRc6y1TYjVMHQzQQF4Gbo2XUU9wG/G1+i11qQmJnEVpiexftzoKUUWFVosLfciTWMAOkx sz9BvHhHmu8svWpmJxpARpIyA9BQh955WV4F9FMmE/elLQ2GkYc73/hYLggPhySycfJvDViL//R 6/WCYIDezwHqRZihJ4Wb8/3bHaaf9bCr9D7/vc3tLlQF1xZWGGw== X-Received: by 2002:a05:600c:1d1c:b0:477:76bf:e1fb with SMTP id 5b1f17b1804b1-488997d1392mr171049655e9.16.1775463170000; Mon, 06 Apr 2026 01:12:50 -0700 (PDT) X-Received: by 2002:a05:600c:1d1c:b0:477:76bf:e1fb with SMTP id 5b1f17b1804b1-488997d1392mr171049355e9.16.1775463169459; Mon, 06 Apr 2026 01:12:49 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4889b5427cfsm142633325e9.1.2026.04.06.01.12.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Apr 2026 01:12:48 -0700 (PDT) From: Stefano Brivio To: Anshu Kumari Subject: Re: [PATCH v1 2/2] tap, tcp, udp: Use rate-limited logging Message-ID: <20260406101247.3d9b3086@elisabeth> In-Reply-To: <20260401182910.669164-1-anskuma@redhat.com> References: <20260401182910.669164-1-anskuma@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Mon, 06 Apr 2026 10:12:48 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: R8pR05CiQ41x1YVSqWEMx7JQvXrM2KozqpelsIqrY3M_1775463170 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: XCAVEMXI2ZTNO7MCIKIEBK6UA4U52T5M X-Message-ID-Hash: XCAVEMXI2ZTNO7MCIKIEBK6UA4U52T5M X-MailFrom: sbrivio@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: passt-dev@passt.top, 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: On Wed, 1 Apr 2026 23:59:10 +0530 Anshu Kumari wrote: > 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 By the way of this ticket, I forgot to mention that as it came up after a discussion on a series by Volker (Volker Diels-Grabsch ), it would be nice to Cc: him on the next version of this patch. > 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)); I had a closer look, and it looks like we're hitting that part for any error reported via ICMP that can be associated to a given UDP socket, so I would say it's part of our regular networking operation, and we should keep it as debug(). > --- > 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))); Similar to the other call Laurent commented on, this should be: info_ratelimit(now, "New guest MAC address observed: %s", eth_ntop(c->guest_mac, bufmac, sizeof(bufmac))); so that arguments visually align with each other. This is the style (somewhat) suggested at: https://docs.kernel.org/process/coding-style.html#breaking-long-lines-and-strings which is the one we follow. > 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); Other than that, and other than the pending comments from Laurent, the patch looks good to me! I would suggest maybe waiting about one more day before posting the next version to give others better chances to review. -- Stefano