On 10/21/26 2:41 PM, Eli Britstein wrote:
> The previous check only tested whether a new fragment's endpoints fell
> inside an existing range and treated any such match as a fragment to be
> dropped on its own. This missed the case where a new fragment fully
> contains an existing one, and it conflated two cases that the kernel and
> RFCs 815, 5722 and 8200 handle differently:
>
> - An exact duplicate (same byte range as an existing fragment) may be
> dropped on its own while the rest of the fragment list is kept for
> later reassembly (RFC 8200).
>
> - An overlapping (but not duplicate) fragment means the whole datagram
> must be silently discarded along with all of its fragments
> (RFC 5722 / RFC 8200).
>
> Detect these two cases separately using closed-interval overlap, and count
> duplicates, as a pre-step towards handling real overlaps and duplicates
> differently.
>
> Assisted-by: composer-2.5-fast, Cursor
> Fixes: 4ea96698f667 ("Userspace datapath: Add fragmentation handling.")
> Signed-off-by: Eli Britstein <[email protected]>
> ---
Some minor commit message nits from an LLM:
This patch splits the ipf fragment checks into exact-duplicate and
overlap cases, adds a duplicate counter, and drops exact duplicates.
> Detect these two cases separately using closed-interval overlap, and count
> duplicates, as a pre-step towards handling real overlaps and duplicates
> differently.
Is "pre-step" accurate here? This patch already handles duplicates
differently:
> + } else if (duped_frag) {
[...]
> + ipf_count(ipf, v6, IPF_NFRAGS_DUPLICATE);
> + dp_packet_delete(pkt);
Before, an exact duplicate was marked CS_INVALID and returned to the
batch. Now it's freed inside ipf. Could the last paragraph say that
duplicates are now dropped?
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
