DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] Bug report: rte_table_hash_ext incorrectly compares signatures
@ 2017-01-21 22:15 Solal Pirelli
  0 siblings, 0 replies; only message in thread
From: Solal Pirelli @ 2017-01-21 22:15 UTC (permalink / raw)
  To: dev

Hi,

I found a bug in the rte_table_hash_ext implementation, hopefully this
mailing list is the right place to report it.

It's pretty simple: in `rte_table_hash_ext.c` (using `add` as an example;
the bug is also elsewhere):
- line 53 declares the bucket signatures as arrays of `uint16_t`
- line 280 computes the key signature, an `uint64_t`
- line 283 shifts the signature by 16 bits to the right, resulting in a
"48-bit" number
- like 293 then compares the bucket signature (16 bits) to the shifted key
signature (48 bits).

Thus, rte_table_hash_ext only works if hashes have their upper 32 bits
unset.

I created a tiny repro:
https://github.com/SolalPirelli/dpdk-table-hash-ext-bug
It tries to insert then retrieve the same key/value pair, with specific
bits set in the hash; as can be seen from the output, the map works fine
when only one of the lower 32 bits is set, but stops working if one of the
upper 32 bits is.

The workaround is simple: the hash function should always clear the upper
32 bits of its output.

(I unfortunately don't have the time right now to provide a properly-tested
patch, sorry)


Cheers,
Solal Pirelli

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2017-01-21 22:16 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-21 22:15 [dpdk-dev] Bug report: rte_table_hash_ext incorrectly compares signatures Solal Pirelli

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).