Re: [PATCH v1 2/2] tap, tcp, udp: Use rate-limited logging

On Mon, Apr 06, 2026 at 10:12:48AM +0200, Stefano Brivio wrote:

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().

Thinking about this again, I agree. Looking at this another way, the error is already being reported at the right level: as an ICMP message to the guest. At the passt level this might be useful for debugging, hence debug() but doesn't represent anything out of the ordinary or worrying. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson