[dpdk-dev] hash: document rte_jhash() boundary behavior

Message ID 20170918194740.23057-1-3chas3@gmail.com (mailing list archive)
State Accepted, archived
Headers

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK

Commit Message

Chas Williams Sept. 18, 2017, 7:47 p.m. UTC
  From: Chas Williams <chas3@att.com>

Due to the uint32_t accesses in the hash computation, keys that aren't
aligned to a uint32_t boundary or multiples of uint32_t in length, may
see accesses beyond the end of the key.  This may cross a page boundary.

Signed-off-by: Chas Williams <chas3@att.com>
---
 lib/librte_hash/rte_jhash.h | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
  

Comments

Luca Boccassi Sept. 19, 2017, 10:07 a.m. UTC | #1
On Mon, 2017-09-18 at 15:47 -0400, Chas Williams wrote:
> From: Chas Williams <chas3@att.com>
> 
> Due to the uint32_t accesses in the hash computation, keys that
> aren't
> aligned to a uint32_t boundary or multiples of uint32_t in length,
> may
> see accesses beyond the end of the key.  This may cross a page
> boundary.
> 
> Signed-off-by: Chas Williams <chas3@att.com>
> ---
>  lib/librte_hash/rte_jhash.h | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/librte_hash/rte_jhash.h
> b/lib/librte_hash/rte_jhash.h
> index 207478c..3eca138 100644
> --- a/lib/librte_hash/rte_jhash.h
> +++ b/lib/librte_hash/rte_jhash.h
> @@ -290,7 +290,10 @@ rte_jhash_32b_2hashes(const uint32_t *k,
> uint32_t length, uint32_t *pc, uint32_t
>  /**
>   * The most generic version, hashes an arbitrary sequence
>   * of bytes.  No alignment or length assumptions are made about
> - * the input key.
> + * the input key.  For keys not aligned to four byte boundaries
> + * or a multiple of four bytes in length, the memory region
> + * just after may be read (but not used in the computation).
> + * This may cross a page boundary.
>   *
>   * @param key
>   *   Key to calculate hash of.

Acked-by: Luca Boccassi <bluca@debian.org>
  
John McNamara Sept. 19, 2017, 1:33 p.m. UTC | #2
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Chas Williams
> Sent: Monday, September 18, 2017 8:48 PM
> To: dev@dpdk.org
> Cc: Richardson, Bruce <bruce.richardson@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Chas Williams <chas3@att.com>
> Subject: [dpdk-dev] [PATCH] hash: document rte_jhash() boundary behavior
> 
> From: Chas Williams <chas3@att.com>
> 
> Due to the uint32_t accesses in the hash computation, keys that aren't
> aligned to a uint32_t boundary or multiples of uint32_t in length, may see
> accesses beyond the end of the key.  This may cross a page boundary.
> 
> Signed-off-by: Chas Williams <chas3@att.com> 


Acked-by: John McNamara <john.mcnamara@intel.com>
  
Thomas Monjalon Oct. 5, 2017, 9:37 p.m. UTC | #3
> > Due to the uint32_t accesses in the hash computation, keys that aren't
> > aligned to a uint32_t boundary or multiples of uint32_t in length, may see
> > accesses beyond the end of the key.  This may cross a page boundary.
> > 
> > Signed-off-by: Chas Williams <chas3@att.com> 
> 
> Acked-by: John McNamara <john.mcnamara@intel.com>

Applied, thanks
  

Patch

diff --git a/lib/librte_hash/rte_jhash.h b/lib/librte_hash/rte_jhash.h
index 207478c..3eca138 100644
--- a/lib/librte_hash/rte_jhash.h
+++ b/lib/librte_hash/rte_jhash.h
@@ -290,7 +290,10 @@  rte_jhash_32b_2hashes(const uint32_t *k, uint32_t length, uint32_t *pc, uint32_t
 /**
  * The most generic version, hashes an arbitrary sequence
  * of bytes.  No alignment or length assumptions are made about
- * the input key.
+ * the input key.  For keys not aligned to four byte boundaries
+ * or a multiple of four bytes in length, the memory region
+ * just after may be read (but not used in the computation).
+ * This may cross a page boundary.
  *
  * @param key
  *   Key to calculate hash of.