https://bugs.dpdk.org/show_bug.cgi?id=2015
Bug ID: 2015
Summary: memif: ring semantics differ from VPP
Product: DPDK
Version: 26.11
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: minor
Priority: Normal
Component: ethdev
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Found when doing AI assisted analysis and comparison of DPDK memif with VPP.
The two memif implementations disagree by one about what the hello
limit fields mean.
DPDK sends h->max_region = ETH_MEMIF_MAX_REGION_NUM - 1, treating the
field as an inclusive maximum index, and checks received indices with
>= against ETH_MEMIF_MAX_REGION_NUM.
VPP sends h->max_region = MEMIF_MAX_REGION (256) and checks received
indices with > rather than >=, so it accepts index 256 and therefore
257 regions. The same > form is used for its ring index checks.
Nothing is memory-unsafe on either side today, because both clamp what
they actually use, and VPP's regions are vectors. But the accepted range
and the advertised range do not agree, and the two stacks do not agree
with each other.
There is no memif specification outside VPP's tree, so this is the kind
of thing that only gets settled by writing it down. It should be pinned
in whatever wire contract comes out of the current memif hardening work,
and DPDK's side adjusted to match once the meaning is agreed.
Raised here so it is on the record and does not get fixed unilaterally
in one stack in a way that breaks the other.
--
You are receiving this mail because:
You are the assignee for the bug.
