See discussion on #1590 for some context.
It's important to cover network ingress paths, but it's unclear if we are doing good job there.
For example, we don't seem to cover even udp_unicast_rcv_skb in net/ipv4/udp.c which is required to cover both UDP stack and, for example, wireguard (which should be reached via udp_queue_rcv_one_skb->encap_rcv).
Maybe these parts are only executed in background threads? But most likely there is something else. Either way we need to understand what exactly is it and if it's async paths, if it's possible to cover them with the remote coverage facility.
Another observation is that IFF_NAPI_FRAGS for tun diverges execution to completely different paths (something called gso). But it's unclear if it affects our ability to cover udp stack or not. Without IFF_NAPI_FRAGS I seem to get more coverage overall, but still no coverage of udp_unicast_rcv_skb.
If we remove IFF_NAPI_FRAGS, most likely we also need to remove IFF_NAPI (this actually affects our current fallback for failed IFF_NAPI_FRAGS). IFF_NAPI without IFF_NAPI_FRAGS leads to async receive path, which is bad for us.
See discussion on #1590 for some context.
It's important to cover network ingress paths, but it's unclear if we are doing good job there.
For example, we don't seem to cover even udp_unicast_rcv_skb in net/ipv4/udp.c which is required to cover both UDP stack and, for example, wireguard (which should be reached via udp_queue_rcv_one_skb->encap_rcv).
Maybe these parts are only executed in background threads? But most likely there is something else. Either way we need to understand what exactly is it and if it's async paths, if it's possible to cover them with the remote coverage facility.
Another observation is that IFF_NAPI_FRAGS for tun diverges execution to completely different paths (something called gso). But it's unclear if it affects our ability to cover udp stack or not. Without IFF_NAPI_FRAGS I seem to get more coverage overall, but still no coverage of udp_unicast_rcv_skb.
If we remove IFF_NAPI_FRAGS, most likely we also need to remove IFF_NAPI (this actually affects our current fallback for failed IFF_NAPI_FRAGS). IFF_NAPI without IFF_NAPI_FRAGS leads to async receive path, which is bad for us.