* [DPDK/other Bug 1883] rte_hash with big cap and key size of 64bytes and more can lead to key store corruption
@ 2026-02-17 20:34 bugzilla
0 siblings, 0 replies; only message in thread
From: bugzilla @ 2026-02-17 20:34 UTC (permalink / raw)
To: dev
http://bugs.dpdk.org/show_bug.cgi?id=1883
Bug ID: 1883
Summary: rte_hash with big cap and key size of 64bytes and more
can lead to key store corruption
Product: DPDK
Version: 26.03
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: other
Assignee: dev@dpdk.org
Reporter: oleksandrn@interfacemasters.com
Target Milestone: ---
Created attachment 340
--> http://bugs.dpdk.org/attachment.cgi?id=340&action=edit
simple repro
I was experimenting with table size of 2^26 and key size of 64 bytes, and
noticed, that deletion was failing for some earlier added entries, after some
digging it seems like the main problem is overflow in key_store offset
calculation, seems like there are multiple places, but as example
new_k = RTE_PTR_ADD(keys, slot_id * h->key_entry_size);
slot_id is u32, and h->key_entry_size is u32 as well, in my case at high
occupancy slot_id can be very high(up to 67mil) which multiplied by 80 will
overflow u32 and will overwrite earlier entries.
lazy fix seem to be making h->key_entry_size u64
Attached simple repro.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2026-02-17 20:34 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-17 20:34 [DPDK/other Bug 1883] rte_hash with big cap and key size of 64bytes and more can lead to key store corruption bugzilla
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.