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

On Fri, 13 Feb 2026 14:45:24 +0800 Yumei Huang wrote:

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.

Hmm, weird, it should return false only for the first *inbound* datagram of a UDP flow.

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.

I haven't really checked, but udp_sock_handler() should anyway be called for the datagram triggering udp_flow_from_sock(), so I don't think you need an extra call to udp_flow_activity() there. But you should check that with a pair of debugging prints, I guess.

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.

Same here, I *thought* that calling udp_flow_activity() from udp_sock_handler() *and* udp_tap_handler() would anyway account for the first datagram, but I didn't check.

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.

Ah, right, good catch. The rules are quite obvious, so you can just add them to the patch, and I'll test them later on Debian anyway. -- Stefano