Re: [PATCH v7 2/2] lib: checksum: Use aligned accesses for ip_fast_csum and csum_ipv6_magic tests

[Guenter Roeck]

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@xxxxxxxxxxxx>
> >
> > 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