Re: [PATCH] Revert "sh: Handle calling csum_partial with misaligned data"

Guenter Roeck <[email protected]>
Newsgroups gmane.linux.ports.sh.devel,gmane.linux.kernel
Message-ID <[email protected]>
On Mon, Mar 25, 2024 at 08:39:39AM +0100, John Paul Adrian Glaubitz wrote:
> Hi Guenter,
> 
> On Sun, 2024-03-24 at 16:18 -0700, Guenter Roeck wrote:
> > This reverts commit cadc4e1a2b4d20d0cc0e81f2c6ba0588775e54e5.
> > 
> > Commit cadc4e1a2b4d ("sh: Handle calling csum_partial with misaligned
> > data") causes bad checksum calculations on unaligned data. Reverting
> > it fixes the problem.
> > 
> >     # Subtest: checksum
> >     # module: checksum_kunit
> >     1..5
> >     # test_csum_fixed_random_inputs: ASSERTION FAILED at lib/checksum_kunit.c:500
> >     Expected ( u64)result == ( u64)expec, but
> >         ( u64)result == 53378 (0xd082)
> >         ( u64)expec == 33488 (0x82d0)
> >     # test_csum_fixed_random_inputs: pass:0 fail:1 skip:0 total:1
> >     not ok 1 test_csum_fixed_random_inputs
> >     # test_csum_all_carry_inputs: ASSERTION FAILED at lib/checksum_kunit.c:525
> >     Expected ( u64)result == ( u64)expec, but
> >         ( u64)result == 65281 (0xff01)
> >         ( u64)expec == 65280 (0xff00)
> >     # test_csum_all_carry_inputs: pass:0 fail:1 skip:0 total:1
> >     not ok 2 test_csum_all_carry_inputs
> >     # test_csum_no_carry_inputs: ASSERTION FAILED at lib/checksum_kunit.c:573
> >     Expected ( u64)result == ( u64)expec, but
> >         ( u64)result == 65535 (0xffff)
> >         ( u64)expec == 65534 (0xfffe)
> >     # test_csum_no_carry_inputs: pass:0 fail:1 skip:0 total:1
> >     not ok 3 test_csum_no_carry_inputs
> >     # test_ip_fast_csum: pass:1 fail:0 skip:0 total:1
> >     ok 4 test_ip_fast_csum
> >     # test_csum_ipv6_magic: pass:1 fail:0 skip:0 total:1
> >     ok 5 test_csum_ipv6_magic
> >  # checksum: pass:2 fail:3 skip:0 total:5
> >  # Totals: pass:2 fail:3 skip:0 total:5
> > not ok 22 checksum
> 
> Can you tell me how the tests are run so I can try to verify this on real hardware?
> 

Please also see
https://lore.kernel.org/lkml/[email protected]/t/
where I reported the problem a while ago. I didn't see a fix, so I figured
I'd submit a revert, following the logic that non-optimized code is better
than buggy code. Obviously a real fix would be preferrable, but I don't
understand sh4 assembler well enough to understand what is happening.

Thanks,
Guenter
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.