passt/flow.c, branch bug209

flow, treewide: Promote priority of selected flow-linked messages

2026-06-22T07:13:46+00:00

Most of out flow specific log messages are debug level for fear of flooding
the logs, even when they report real error conditions that might be off
significance.

Now that we have the mechanisms for log message rate limiting, we can do
better.  Promote many flow related messages to warning or error level, with
rate limiting.  While we're there add ratelimiting to a handful of existing
warning or error level messages.

They general heuristic is to promote messages that report a failure which
is not something that should be triggered by the guest doing something
weird.  This mostly means failures from socket operations we expect to be
legitimate.

Adding the ratelimiting means plumbing the 'now' timestamp through much
more of the code, hence the large churn.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

flow, udp: Fix errno handling in udp_flow_sock()

2026-06-22T07:13:46+00:00

flowside_connect() behaves much like connect(2) itself, returning -1 on
error with errno set to the error code.  One of the callers, in
udp_flow_sock(), uses the errno code with flow_dbg_perror() *after* it's
called epoll_del() and close() either of which could clobber errno.

Fix that by moving the debug message earlier: there's no reason it has to
wait until the epoll_del() and close().

While we're at it, adjust the comment on flowside_connect() to clarify
that it sets errno (rather than, say, returning an error code).

Suggested-by: Stefano Brivio 
Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

flow: Include flow details with higher priority log messages

2026-06-22T07:13:46+00:00

Currently flow_log() and related functions / macros have a 'details'
parameter which indicates whether to add extra messages with details of the
flow's addresses.  This is still a bit awkward to invoke, and only used in
a few places.  Change the logic, to automatically include the details if
and only if the log priority is greater than LOG_DEBUG.

Rationale:

If at debug log level, there are already a bunch of debug messages tracking
the flow life cycle, which include those details (we make sure to retain
those).  It's usually pretty easy to cross reference a specific flow debug
message with the flow's history including the details.

If at higher log level, and we generate a flow-connected error or warning
we don't have those life cycle messages.  So, just giving the flow index
doesn't really tell you anything about which flow tripped the error.
Adding the address details make the error message significantly more
useful.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

flow: Indent flow details messages

2026-06-22T07:13:46+00:00

flow_log__() has the option to append an extra log message with address
details of the flow, to give more context to errors or warnings.  Add an
indent to this part of the message, to emphasise that it's additional
information related to a nearby message, rather than a message in its own
right.

Suggested-by: Stefano Brivio 
Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

flow: Regularise flow specific logging helpers

2026-06-22T07:13:46+00:00

flow.h has a collection of logging helpers that automatically include
information about a specific flow.  Which variants are present are a bit
ad-hoc, based on what we happened to want use (e.g. there are no
LOG_WARNING level versions, at present).  There's also a rather awkward
and only occasionally used flow_log_details_() helper to print additional
log messages with more details of the flow (basically its addresses).
It's particularly awkward to try to combine that with ratelimiting.

Re-organise this to be based around a flow_log__() internal helper, which
has bool parameters to include strerror() / perror information and/or
the extra details.  Add wrapper macros for all combinations of perror,
ratelimiting and DEBUG/WARNING/ERR priorities.

Be a little more consistent about parameter order between the various
functions / macros / wrappers while we're at it.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

flow: Correct misleading signature of flowside_sock_l4()

2026-06-16T21:49:53+00:00

flowside_sock_l4() takes a @tgt parameter with the side to create a socket
for.  The name is misleading, however, although ICMP only uses it for the
target side of the flow, UDP can use it for either or both sides.  TCP
doesn't use it at all.  Rename it to @side.

While we're there remove the stale comment for the @data paremeter which
was removed in 05972c7c4daf.

Fixes: 05972c7c4daf ("util: Move epoll registration out of sock_l4_sa()")
Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

clang-tidy: Squash inconsistent brace warnings in foreach macros

2026-05-11T22:04:03+00:00

clang-tidy, at least as of 22.1.4 complains about if/else statements with
inconsistent braces.  We generally do want consistend bracing per our
coding style.  However, some of our foreach macros generate inconsistent
bracing in a way that can't really be avoided.  Add suppressions to stop
clang-tidy complaining about these.

Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
Signed-off-by: Stefano Brivio

inany: Prepare inany.[ch] for sharing with pesto tool

2026-05-07T06:06:30+00:00

inany contains a number of helpful functions for dealing with addresses
which might be IPv4 or IPv6.  We're going to want to use that in pesto.
For the most part inany doesn't depend on other passt/pasta internals,
however it does depend on siphash.h, which pesto doesn't need.

Move the single dependent function, inany_siphash_feed() to siphash.h,
renaming to match.  Use that include inany.[ch] into pesto as well as
passt/pasta.  While we're there reformat pesto.c's header comment to match
the convention used in most other files.

Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
Signed-off-by: Stefano Brivio

fwd: Store forwarding tables indexed by (origin) pif

2026-03-28T13:35:48+00:00

Currently we store the inbound (PIF_HOST) and outbound (PIF_SPLICE)
forwarding tables in separate fields of struct ctx.  In a number of places
this requires somewhat awkward if or switch constructs to select the
right table for updates.  Conceptually simplify that by using an index of
forwarding tables by pif, which as a bonus keeps track generically which
pifs have implemented forwarding tables so far.

For now this doesn't simplify a lot textually, because many places that
need this also have other special cases to apply by pif.  It does simplify
a few crucial places though, and we expect it will become more useful as
the flexibility of the forwarding table is improved.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

serialise: Add helpers for serialising unsigned integers

2026-03-28T13:35:43+00:00

Add helpers to serialise/deserialise unsigned integers, handling endian
conversion so that the stream format is consistent regardless of host
endiannness.  Currently we only use this on one place: sending the number
of flows during migration.  We're going to have more use for this as we
add dynamic configuration updates, so these will become more useful.

For now we only need a 32-bit version, however define the functions with
a macro so we can easily add other integer widths when we need them.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio