On 2/26/24 03:34, Christophe Leroy wrote:
Le 23/02/2024 à 23:11, Charlie Jenkins a écrit :
The test cases for ip_fast_csum and csum_ipv6_magic were not properly
aligning the IP header, which were causing failures on architectures
that do not support misaligned accesses like some ARM platforms. To
solve this, align the data along (14 + NET_IP_ALIGN) bytes which is the
standard alignment of an IP header and must be supported by the
architecture.
I'm still wondering what we are really trying to fix here.
All other tests are explicitely testing that it works with any alignment.
Shouldn't ip_fast_csum() and csum_ipv6_magic() work for any alignment as
well ? I would expect it, I see no comment in arm code which explicits
that assumption around those functions.
Isn't the problem only the following line, because csum_offset is
unaligned ?
csum = *(__wsum *)(random_buf + i + csum_offset);
Otherwise, if there really is an alignment issue for the IPv6 source or
destination address, isn't it enough to perform a 32 bits alignment ?
It isn't just arm.
Question should be what alignments the functions are supposed to be able
to handle, not what they are optimized for. If byte and/or half word alignments
are expected to be supported, there is still architecture code which would
have to be fixed. Unaligned accesses are known to fail on hppa64/parisc64
and on sh4, for example. If unaligned accesses are expected to be handled,
it would probably make sense to add a separate test case, though, to clarify
that the test fails due to alignment issues, not due to input parameters.
Thanks,
Guenter
