On 2/27/24 09:54, Charlie Jenkins wrote:
It's been suggested during the discussion that alignment tests should be
added later in a follow-up patch. So for the time being I'm trying to
find a compromise and get the existing tests working on all platforms
but with a smaller alignment than the 16-bytes alignment brought by
Charlie's v10 patch. And a 4 bytes alignment seemed to me to be a good
compromise for this fix. The idea is also to make the fix as minimal as
possible, unlike Charlie's patch that is churning up the tests quite
heavily.
Do you have a list of platforms this is failing on? I haven't seen any
reports that haven't been fixed.
This is what I carry locally on top of v6.8-rc6:
097b149e4acb parisc: More csum_ipv6_magic fixes
15bf67a115eb kunit: Fix again checksum tests on big endian CPUs
bebe776d36ea parisc: Fix csum_ipv6_magic on 64-bit systems
523208f03063 parisc: Fix csum_ipv6_magic on 32-bit systems
a9dda1971c72 parisc: Fix ip_fast_csum
2ad0a6850b64 Revert "sh: Handle calling csum_partial with misaligned data"
7113cc414860 lib: checksum: Use aligned accesses for ip_fast_csum and csum_ipv6_magic tests
I also have
0dd01a364cb7 lib: checksum: Add some corner cases to IPv6 checksum tests
e767cce6598b lib: checksum: Add tests for unaligned IPv6 addresses
which I may submit or not depending on the outcome of this discussion.
In other words, parisc and sh4 are currently known to be broken in the
upstream kernel, with fixes pending. On top of that, arm:mps2-an385
(probably all arm:nommu systems) crashes hard if csum_ipv6_magic()
is called with an unaligned address.
This is the "known" list of failures. I don't currently run kunit tests
on nios2 or riscv32, for example, nor on any architectures with no qemu
support.
On a side note, most architectures don't handle "len + proto" overflows.
While 'len' is a 32-bit parameter, IPv6 only allows for a 16-bit length
field. Many implementations of csum_ipv6_magic() specifically do
not handle such overflows because that would be pointless and require
extra code for no good reason. The current test code doesn't generate
such overflows, but its 'len' parameter is almost always larger than
16 bit and thus not realistic. Maybe it would make sense to limit
the range of 'len' to 16 bit when calling csum_ipv6_magic().
Thanks,
Guenter
