passt, branch 2026_01_20.386b5f5

flow: Remove EPOLLFD_ID_INVALID

2026-01-20T18:37:53+00:00

As all flows are now registered with an epollid at creation, we no
longer need to test if a flow is in epoll.  Remove all related code
including flow_in_epoll() and flow_epollid_clear().

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

tcp: Register fds with epoll at flow creation

2026-01-20T18:37:46+00:00

Register connection sockets with epoll using empty events
(events=0) in tcp_conn_from_tap(), tcp_tap_conn_from_sock()
and tcp_flow_repair_socket().

This allows tcp_epoll_ctl() to always use EPOLL_CTL_MOD, removing
the need to check whether fds are already registered. As a result, the
conditional ADD/MOD logic is no longer needed, simplifying the function.

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

tcp_splice: Register fds with epoll at flow creation

2026-01-20T18:37:39+00:00

Register both splice connection sockets with epoll using empty events
(events=0) in tcp_splice_connect(), before initiating the connection.

This allows tcp_splice_epoll_ctl() to always use EPOLL_CTL_MOD, removing
the need to check whether fds are already registered. As a result, the
conditional ADD/MOD logic is no longer needed, simplifying the function.

If the second flow_epoll_set() fails after the first succeeds, we don't
need explicit rollback: tcp_splice_conn_from_sock() sets the CLOSING
flag on error, and conn_flag() handles it by calling epoll_del() for
both sockets.

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

conf, pasta: Add --splice-only option

2026-01-19T08:12:27+00:00

This patch introduces a mode where we only forward loopback connections
and traffic between two namespaces (via the loopback interface, 'lo'),
without a tap device.

It might be used to fix up podman IPv4 / IPv6 loopback mapping when using
rootlesskit for forwarding ports, or a way to implement isolated containers.

In this mode, --host-lo-to-ns-lo and --no-icmp are automatically enabled.
Option --no-splice is rejected.

Link: https://bugs.passt.top/show_bug.cgi?id=149
Signed-off-by: Yumei Huang 
Signed-off-by: Stefano Brivio

flow, fwd: Optimise forwarding rule lookup using epoll ref when possible

2026-01-18T11:48:09+00:00

Now that listening sockets include a reference to the forwarding rule
which created them we can, in many cases, avoid a linear search of the
forwarding table when we want to find the relevant rule.  Instead we
can take the rule index from the socket's epoll reference, and use
that to immediately find the correct rule.

This is conceptually simple, but requires a moderate amount of
plumbing to get the index from the reference through to the rule
lookup.  We still allow fall back to linear search if we don't have
the index, and this may (rarely) be used in the udp_flush_flow() case,
where we could get packets for one flow on a different flow's socket,
rather than through a listening socket as usual.

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

fwd, tcp, udp: Add forwarding rule to listening socket epoll references

2026-01-18T11:48:06+00:00

Now that we have a table of all our forwarding rules, every listening
socket can be associated with a specific rule.  Add an index allowing us to
locate that rule from the socket's epoll reference.  We don't use it yet,
but we'll use it to optimise rule lookup when forwarding new flows.

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

fwd: Remap ports based directly on forwarding rule

2026-01-18T11:48:03+00:00

Currently we remap port numbers based on the legacy delta[] array, which
is indexed only by original port number, not the listening address.  Now
that we look up a forwarding rule entry in flow_target(), we can use this
entry to directly determine the correct remapped port.  Implement this,
and remove the old delta[] array.

Link: https://bugs.passt.top/show_bug.cgi?id=187
Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

flow, fwd: Consult rules table when forwarding a new flow from socket

2026-01-18T11:48:01+00:00

We now have a formal array of forwarding rules.  However, we don't actually
consult it when we forward a new flow.  Instead we rely on (a) implicit
information (we wouldn't be here if there wasn't a listening socket for the
rule) and (b) the legacy delta[] data structure.

Start addressing this, by searching for a matching forwarding rule when
attempting to forward a new flow.  For now this is incomplete:
 * We only do this for socket-initiated flows
 * We make a potentially costly linear lookup
 * We don't actually use the matching rule for anything yet

We'll address each of those in later patches.

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

fwd: Generate auto-forward exclusions from socket fd tables

2026-01-18T11:47:58+00:00

When auto-forwarding based on port scans, we must exclude our own
listening ports, to avoid circular forwards.  Currently we use the
(previous value of the) forwarding bitmaps for the reverse direction
to determine that.

Instead, generate it from the tables of listening sockets that we now
maintain.  For now this seems like a lot more work to get to the same
place.  However, it does mean we're basing our exclusions directly on the
relevant information: which of the scanned listens belong to us.  More
importantly, it's a step towards removing the bitmaps entirely.

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

conf, fwd: Check forwarding table for conflicting rules

2026-01-18T11:47:53+00:00

It's possible for a user to supply conflicting forwarding parameters, e.g.
    $ pasta -t 80:8080 -t 127.0.0.1/80:8888

We give a warning in this case, but it's based on the legacy
forwarding bitmaps.  This is too strict, because it will also warn on
cases that shouldn't conflict because they use different addresses,
e.g.
    $ pasta -t 192.0.2.1/80:8080 127.0.0.1/80:8888

Theoretically, it's also too loose because it won't take into account
auto-scan forwarding rules.  We can't hit that in practice now,
because we only ever have one auto-scan rule and nothing else, but we
want to remove that restriction in future.

Replace the bitmap based check with a check based on actually scanning
the forwarding rules for conflicts.

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