From: "D. Jeff Dionne" <djeffdionne@gmail.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Rich Felker <dalias@libc.org>,
linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Problems with csum_partial with misaligned buffers on sh4 platform
Date: Sun, 11 Feb 2024 12:41:16 +0900 [thread overview]
Message-ID: <8C704EE6-7B5E-4569-B9C3-84B2CBADA102@gmail.com> (raw)
In-Reply-To: <0a0fbbd8-17dd-4f4c-9513-f3ac9749890b@roeck-us.net>
I remember there being problems with alignment on SH targets in the network stack. IIRC, wireguard triggered it in actual use, seems to me it had to do with skb alignment.
Rich Felker may remember more, but I don’t think we implemented a (complete) solution.
Cheers,
J.
> On 11 Feb 2024, at 07:03, Guenter Roeck <linux@roeck-us.net> wrote:
>
> Hi Adrian,
>
>> On 2/10/24 12:12, John Paul Adrian Glaubitz wrote:
>> Hi Guenter,
>>> On Sat, 2024-02-10 at 07:12 -0800, Guenter Roeck wrote:
>>> when running checksum unit tests on sh4 qemu emulations, I get the following
>>> errors.
>>>
>>> KTAP version 1
>>> # 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)
>>> 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)
>>> 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)
>>> not ok 3 test_csum_no_carry_inputs
>>> ok 4 test_ip_fast_csum
>>> ok 5 test_csum_ipv6_magic
>>> # checksum: pass:2 fail:3 skip:0 total:5
>>>
>>> The above is with from a little endian system. On a big endian system,
>>> the test result is as follows.
>>>
>>> KTAP version 1
>>> # 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 == 33488 (0x82d0)
>>> ( u64)expec == 53378 (0xd082)
>>> 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 == 255 (0xff)
>>> not ok 2 test_csum_all_carry_inputs
>>> # test_csum_no_carry_inputs: ASSERTION FAILED at lib/checksum_kunit.c:565
>>> Expected ( u64)result == ( u64)expec, but
>>> ( u64)result == 1020 (0x3fc)
>>> ( u64)expec == 0 (0x0)
>>> not ok 3 test_csum_no_carry_inputs
>>> # test_ip_fast_csum: ASSERTION FAILED at lib/checksum_kunit.c:589
>>> Expected ( u64)expected == ( u64)csum_result, but
>>> ( u64)expected == 55939 (0xda83)
>>> ( u64)csum_result == 33754 (0x83da)
>>> not ok 4 test_ip_fast_csum
>>> # test_csum_ipv6_magic: ASSERTION FAILED at lib/checksum_kunit.c:617
>>> Expected ( u64)expected_csum_ipv6_magic[i] == ( u64)csum_ipv6_magic(saddr, daddr, len, proto, csum), but
>>> ( u64)expected_csum_ipv6_magic[i] == 6356 (0x18d4)
>>> ( u64)csum_ipv6_magic(saddr, daddr, len, proto, csum) == 43586 (0xaa42)
>>> not ok 5 test_csum_ipv6_magic
>>> # checksum: pass:0 fail:5 skip:0 total:5
>>>
>>> Note that test_ip_fast_csum and test_csum_ipv6_magic fail on all big endian
>>> systems due to a bug in the test code, unrelated to this problem.
>>>
>>> Analysis shows that the errors are seen only if the buffer is misaligned.
>>> Looking into arch/sh/lib/checksum.S, I found commit cadc4e1a2b4d2 ("sh:
>>> Handle calling csum_partial with misaligned data") which seemed to be
>>> related. Reverting that commit fixes the problem.
>>> This suggests that something may be wrong with that commit. Alternatively,
>>> of course, it may be possible that something is wrong with the qemu
>>> emulation, but that seems unlikely.
>> I have not run these tests before. Can you tell me how these are run,
>> so I can verify these reproduce on real hardware?
>
> Enabling CONFIG_KUNIT and CONFIG_CHECKSUM_KUNIT on top of a working
> configuration should do the trick. Both can be built as module,
> so presumably one can build and load them separately. I have not tried
> that, though - I always build them into the kernel and boot the resulting
> image.
>
> Hope this helps,
> Guenter
>
>
next prev parent reply other threads:[~2024-02-11 3:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-10 15:12 Guenter Roeck
2024-02-10 20:12 ` John Paul Adrian Glaubitz
2024-02-10 21:54 ` Guenter Roeck
2024-02-11 3:41 ` D. Jeff Dionne [this message]
2024-02-11 16:12 ` Rich Felker
2024-02-11 9:53 ` Geert Uytterhoeven
2024-02-11 14:35 ` Yoshinori Sato
2024-03-11 17:04 ` Guenter Roeck
2024-03-18 15:04 ` Linux regression tracking (Thorsten Leemhuis)
2024-03-18 15:32 ` Guenter Roeck
2024-03-18 15:58 ` Linux regression tracking (Thorsten Leemhuis)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8C704EE6-7B5E-4569-B9C3-84B2CBADA102@gmail.com \
--to=djeffdionne@gmail.com \
--cc=dalias@libc.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=ysato@users.sourceforge.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®