Re: [PATCH] udp: Split activity timeouts for UDP flows

On Fri, Feb 13, 2026 at 5:51 AM Stefano Brivio wrote:

Oops, I missed one point at a first review, and also during a quick test.

I just tried outbound DNS queries in pasta with single responses, not inbound traffic or passt in vhost-user mode. Then I realised that:

On Thu, 12 Feb 2026 16:04:14 +0800 Yumei Huang wrote:

...

[...] @@ -954,6 +964,7 @@ void udp_sock_handler(const struct ctx *c, union epoll_ref ref,

flow_trace(uflow, "Received data on reply socket"); uflow->ts = now->tv_sec; + udp_flow_activity(uflow, !tosidx.sidei);

...this only covers three of the four paths we need to act upon:

1. inbound datagrams received on the reply socket via udp_buf_sock_to_tap(), called from here

2. inbound datagrams received on the reply socket in passt's vhost-user mode, that's udp_vu_sock_recv(), also called from here

3. "spliced" sockets (that's not really the case for UDP, we can't call splice(), but a pair of recvmmsg() / sendmmsg()), that is, loopback UDP traffic, handled by udp_sock_to_sock(), called from here as well

but not:

4. outbound, non-spliced datagrams from container/guest: that's udp_tap_handler(), in both vhost-user and non-vhost-user cases, or udp_flow_from_tap() in udp_flow.c.

I guess we want to take care of this directly from udp_flow_from_tap(), for consistency, because that's also where we update the timestamp value:

sidx = flow_lookup_sa(c, IPPROTO_UDP, pif, s_in, dst, port); if ((uflow = udp_at_sidx(sidx))) { uflow->ts = now->tv_sec;

^^^ here

return flow_sidx_opposite(sidx); }

I haven't really tested this side of it but it should be fairly easy with socat and a UDP "server" inside pasta or a guest.

Somehow, it worked well in my tests with pasta, it looks like the if condition always returns false. But now when I test with passt, it becomes an issue and we need to track the activity here as you mentioned. Besides, I also noticed we update the timestamp value in udp_flow_from_sock() as well. I feel we should call udp_flow_activity() there too, but couldn't come up with a test to prove it. On top of it, I just found two other issues. 1. in udp_flow_new(), we should initialize uflow->activity[INISIDE] to 1 instead of 0. Otherwise, we fail to track the first datagram. 2. I guess we need to add the profs entries (nf_conntrack_udp_timeout and nf_conntrack_udp_timeout_stream) to apparmor like the tcp ones in https://passt.top/passt/commit/?id=2aa63237109b97a55c85e4c86c72db0d055bfe7a. I don't have an environment to test it now. Maybe I can set up a debian vm later.

Another thing I noticed later:

...

[...]

diff --git a/udp_flow.h b/udp_flow.h index 14e0f92..158a0f6 100644 --- a/udp_flow.h +++ b/udp_flow.h @@ -16,6 +16,7 @@ * @flush1: @s[1] may have datagrams queued for other flows * @ts: Activity timestamp * @s: Socket fd (or -1) for each side of the flow + * @activity: Activity for each side of the flow */ struct udp_flow { /* Must be first element */ @@ -29,8 +30,20 @@ struct udp_flow {

time_t ts; int s[SIDES]; + uint8_t activity[SIDES]; };

+/** + * udp_flow_activity() - Track activity of a udp flow + * @uflow: UDP flow + * @sidei: Side index of the flow + */ +static inline void udp_flow_activity(struct udp_flow *uflow, unsigned int sidei) +{ + if (uflow->activity[sidei] < UINT8_MAX) + uflow->activity[sidei]++; +}

This is an inline function in a header file for no good reason. It could be a normal static function in udp.c. See also:

https://www.kernel.org/doc/html/latest/process/coding-style.html#the-inline-...

...and yes, it's two lines of code, but there's really no reason to decide we want to inline this instead of letting the compiler decide.

I see. I will remove the inline and move the function to udp.c

-- Stefano

-- Thanks, Yumei Huang