On Fri, Feb 13, 2026 at 5:51 AM Stefano Brivio <sbrivio@redhat.com> 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 <yuhuang@redhat.com> 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-disease

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