Hi Helge,
On 2/16/24 04:38, Helge Deller wrote:
* Guenter Roeck <linux@xxxxxxxxxxxx>:
hppa 64-bit systems calculates the IPv6 checksum using 64-bit add
operations. The last add folds protocol and length fields into the 64-bit
result. While unlikely, this operation can overflow. The overflow can be
triggered with a code sequence such as the following.
/* try to trigger massive overflows */
memset(tmp_buf, 0xff, sizeof(struct in6_addr));
csum_result = csum_ipv6_magic((struct in6_addr *)tmp_buf,
(struct in6_addr *)tmp_buf,
0xffff, 0xff, 0xffffffff);
Fix the problem by adding any overflows from the final add operation into
the calculated checksum. Fortunately, we can do this without additional
cost by replacing the add operation used to fold the checksum into 32 bit
with "add,dc" to add in the missing carry.
Gunter,
Thanks for your patch for 32- and 64-bit systems.
But I think it's time to sunset the parisc inline assembly for ipv4/ipv6
checksumming.
The patch below converts the code to use standard C-coding (taken from the
s390 header file) and it survives the v8 lib/checksum patch.
Opinions?
Works for me.
Helge
Subject: [PATCH] parisc: Fix csum_ipv6_magic on 32- and 64-bit machines
Guenter noticed that the 32- and 64-bit checksum functions may calculate
wrong values under certain circumstances. He fixed it by usining
using
corrected carry-flags added, but overall I think it's better to convert
away from inline assembly to generic C-coding. That way the code is
much cleaner and the compiler can do much better optimizations based on
the target architecture (32- vs. 64-bit). Furthermore, the compiler
generates nowadays much better code, so inline assembly usually won't
give any benefit any longer.
Signed-off-by: Helge Deller <deller@xxxxxx>
Noticed-by: Guenter Roeck <linux@xxxxxxxxxxxx>
That would be a new tag. Maybe use "Reported-by:", or just drop it.
Maybe also consider adding
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Other than that,
Tested-by: Guenter Roeck <linux@xxxxxxxxxxxx>
Thanks,
Guenter
