On 30/04/2026 12:25, Eelco Chaudron wrote:
External email: Use caution opening links or attachments
On 1 Apr 2026, at 11:13, Eli Britstein wrote:
Introduce a new netdev type - netdev-doca.
In order to compile, need to install doca on the build machine.
Hi Eli,
I was running the DOCA test suite patch[1] on this series, and I get a
few errors. The earlier tunnel related errors are gone though.
95: conntrack - IPv4 fragmentation FAILED
(system-traffic.at:4881)
97: conntrack - IPv4 fragmentation expiry FAILED
(system-traffic.at:5002)
105: conntrack - IPv6 fragmentation FAILED
(system-traffic.at:5264)
107: conntrack - IPv6 fragmentation expiry FAILED
(system-traffic.at:5390)
These tests pass fine with check-dpdk and check-dpdk-offloads.
I did not investigate the issues, as I'm focussing on the general
review of the series, so please take a look.
Thanks Eelco for this info.
I looked into it.
The RC is that there is a UAF in the following scenario:
1. A frag packet is added to frag_list in ipf module, and not returned
to the mempool.
2. the datapath is destroyed. At this point, we first remove the ports,
and only then destroy CT/IPF.
3. When a doca port is destroyed, it frees its packet mempool
(rte_mempool_free). in this process, the memory is zeroed in dpdk code:
lib/eal/common/malloc_elem.c -> malloc_elem_free() -> memset(ptr, 0,
data_len).
4. When ipf_destroy occurs, the packet is already free. It crashes when
IPF tries to do dp_packet_delete().
With DPDK, there is this commit that frees a mempool only when it's
"full", meaning all its mbufs are returned to the pool:
91fccdad72a2 ("netdev-dpdk: Free mempool only when no in-use mbufs.")
With this, the mempool is not destroyed at all unless another dpdk port
is configured, then the sweep mechanism will destroy it.
IMO, this behavior is a kind of a WA, for which I'm not sure what is the
correct solution.
I will add similar doca-sweep for now, but I think this is not correct.
WDYT?
PS: I had a lot of trouble running the tests. There are few fixes to the
infrastructure that I will post.
Cheers,
Eelco
[1]:
https://patchwork.ozlabs.org/project/openvswitch/patch/e88f13b8266bd6bb792a522b8b323e76923f376e.1777380423.git.echau...@redhat.com/
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
