Re: [ovs-dev] [PATCH v3] hash, jhash: Fix unaligned access to the hash remainder.

2024-05-03 Thread Ilya Maximets
On 5/3/24 13:44, Simon Horman wrote: > On Fri, May 03, 2024 at 07:44:13AM +0200, Ales Musil wrote: >> Partially revert db5a101931c5, this was to avoid warning, however we >> shouldn't use pointer to "uint32_t" when the data are potentially >> unaligned [0]. Use pointer to "uint8_t" right from the

Re: [ovs-dev] [PATCH v3] hash, jhash: Fix unaligned access to the hash remainder.

2024-05-03 Thread Simon Horman
On Fri, May 03, 2024 at 07:44:13AM +0200, Ales Musil wrote: > Partially revert db5a101931c5, this was to avoid warning, however we > shouldn't use pointer to "uint32_t" when the data are potentially > unaligned [0]. Use pointer to "uint8_t" right from the start, this > requires us to use

Re: [ovs-dev] [PATCH v3] hash, jhash: Fix unaligned access to the hash remainder.

2024-05-03 Thread Eelco Chaudron
On 3 May 2024, at 7:44, Ales Musil wrote: > Partially revert db5a101931c5, this was to avoid warning, however we > shouldn't use pointer to "uint32_t" when the data are potentially > unaligned [0]. Use pointer to "uint8_t" right from the start, this > requires us to use ALIGNED_CAST for the

[ovs-dev] [PATCH v3] hash, jhash: Fix unaligned access to the hash remainder.

2024-05-02 Thread Ales Musil
Partially revert db5a101931c5, this was to avoid warning, however we shouldn't use pointer to "uint32_t" when the data are potentially unaligned [0]. Use pointer to "uint8_t" right from the start, this requires us to use ALIGNED_CAST for the get_unaligned_u32, which is fine in that case, because