On 3 May 2026, at 13:57, Eli Britstein wrote:
> 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?
I've included Mike and Kevin who worked on ipf before. Maybe they
have some more insight into how to fix this.
>
> PS: I had a lot of trouble running the tests. There are few fixes to the
> infrastructure that I will post.
Interested to find out what your problems are, as I had no problems
following the documentation. Anyhow, I can include your changes (if you
reply to the RFC patch), or you can include my patch in your series.
Cheers,
Eelco
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
