[PATCH v2 08/10] hash: fix unaligned access in predictable RSS

David Marchand david.marchand at redhat.com
Tue Jul 8 09:32:15 CEST 2025


On Tue, Jul 1, 2025 at 10:36 AM Konstantin Ananyev
<konstantin.ananyev at huawei.com> wrote:
> > Caught by UBSan:
> >
> > ../lib/hash/rte_thash.c:421:8: runtime error: load of misaligned address
> >       0x0001816c2da3 for type 'uint32_t' (aka 'unsigned int'),
> >       which requires 4 byte alignment
> >
> > Fixes: 28ebff11c2dc ("hash: add predictable RSS")
> > Cc: stable at dpdk.org
> >
> > Signed-off-by: David Marchand <david.marchand at redhat.com>
> > ---
> >  lib/hash/rte_thash.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/lib/hash/rte_thash.c b/lib/hash/rte_thash.c
> > index 6c662bf14f..6d4dbea6d7 100644
> > --- a/lib/hash/rte_thash.c
> > +++ b/lib/hash/rte_thash.c
> > @@ -415,10 +415,10 @@ generate_subkey(struct rte_thash_ctx *ctx, struct thash_lfsr *lfsr,
> >  static inline uint32_t
> >  get_subvalue(struct rte_thash_ctx *ctx, uint32_t offset)
> >  {
> > -     uint32_t *tmp, val;
> > +     uint32_t tmp, val;
> >
> > -     tmp = (uint32_t *)(&ctx->hash_key[offset >> 3]);
> > -     val = rte_be_to_cpu_32(*tmp);
> > +     memcpy(&tmp, &ctx->hash_key[offset >> 3], sizeof(tmp));
> > +     val = rte_be_to_cpu_32(tmp);
>
> Just wonder do you guys consider it as a real one?
> AFAIK, all architectures that we care about do support unaligned load for 32-bit integers.

Well this is undefined behavior, regardless of what the architecture support.
And the compiler may end up generating wrong code.

I could revisit this change with the aliasing trick (used for rte_memcpy).


-- 
David Marchand



More information about the dev mailing list