lkml.org 
[lkml]   [2024]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v7 2/2] lib: checksum: Use aligned accesses for ip_fast_csum and csum_ipv6_magic tests
From
On 2/12/24 16:32, Charlie Jenkins wrote:
> On Mon, Feb 12, 2024 at 04:14:49PM -0800, Guenter Roeck wrote:
>> On 2/12/24 12:33, Charlie Jenkins wrote:
>>> The test cases for ip_fast_csum and csum_ipv6_magic were failing on a
>>> variety of architectures that are big endian or do not support
>>> misalgined accesses. Both of these test cases are changed to support big
>>> and little endian architectures.
>>>
>>> The test for ip_fast_csum is changed to align the data along (14 +
>>> NET_IP_ALIGN) bytes which is the alignment of an IP header. The test for
>>> csum_ipv6_magic aligns the data using a struct. An extra padding field
>>> is added to the struct to ensure that the size of the struct is the same
>>> on all architectures (44 bytes).
>>>
>>> Fixes: 6f4c45cbcb00 ("kunit: Add tests for csum_ipv6_magic and ip_fast_csum")
>>> Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
>>
>> This thing really wants to annoy me. Now I get:
>>
>> # test_csum_ipv6_magic: ASSERTION FAILED at lib/checksum_kunit.c:494
>> Expected ( u64)csum_result == ( u64)expected, but
>> ( u64)csum_result == 46543 (0xb5cf)
>> ( u64)expected == 46544 (0xb5d0)
>> not ok 5 test_csum_ipv6_magic
>>
>> with the parisc64 tests. All other architectures / platforms work fine
>> after applying the various pending fixes. It looks like a carry gets
>> lost somewhere, but I have not been able to figure out where exactly
>> that happens. This only happens with the 64-bit hppa assembler code.
>>
>> Guenter
>>
>
> How do you test parisc64? It's not in buildroot which I have been using
> to test the other architectures.
>

Its qemu support is quite new. 32 bit userspace should work.

The errors are quite interesting.

[ 16.989782] ###### i=1 len=0xd22c123d proto=0xb1 csum=0x88e31421 expected=0xb5d0 -> csum 0xb5cf
[ 16.990249] ###### i=3 len=0xb15e4531 proto=0xba csum=0xa2853676 expected=0xe6c1 -> csum 0xe6c0
[ 16.992119] ###### i=5 len=0xbad8adbb proto=0xce csum=0x9e498ff7 expected=0xa836 -> csum 0xa835
[ 16.992498] ###### i=7 len=0xceeaefca proto=0x5c csum=0x2c29f715 expected=0xe87c -> csum 0xe87b
[ 16.992769] ###### i=9 len=0x5c1d4d09 proto=0x8c csum=0x1fe21431 expected=0x5875 -> csum 0x5874
[ 16.993026] ###### i=11 len=0x8c075723 proto=0x93 csum=0x1f6f03e1 expected=0xd361 -> csum 0xd360
[ 16.993282] ###### i=13 len=0x93195303 proto=0x8e csum=0x45499a3b expected=0xdd50 -> csum 0xdd4f
[ 16.993538] ###### i=15 len=0x8e0c125d proto=0x9a csum=0x8ab89b8c expected=0xad6b -> csum 0xad6a
[ 16.993790] ###### i=17 len=0x9a03e5a2 proto=0x7e csum=0x43d23b4e expected=0x90b5 -> csum 0x90b4

Every odd index fails, and the returned value is one less than the expected value. It is almost
as if something goes wrong with 64-bit loads from 32-bit aligned addresses. I'll do some more
debugging.

Guenter


\
 
 \ /
  Last update: 2024-05-27 15:00    [W:0.044 / U:1.508 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site