[PATCH] powerpc: fix csum_ipv6_magic() on little endian platforms

2018-09-09 Thread Christophe Leroy
On little endian platforms, csum_ipv6_magic() keeps len and proto in
CPU byte order. This generates a bad results leading to ICMPv6 packets
from other hosts being dropped by powerpc64le platforms.

In order to fix this, len and proto should be converted to network
byte order ie bigendian byte order. However checksumming 0x12345678
and 0x56341278 provide the exact same result so it is enough to
rotate the sum of len and proto by 1 byte.

PPC32 only support bigendian so the fix is needed for PPC64 only

Fixes: e9c4943a107b ("powerpc: Implement csum_ipv6_magic in assembly")
Reported-by: Jianlin Shi 
Reported-by: Xin Long 
Cc:  # 4.18+
Signed-off-by: Christophe Leroy 
---
 arch/powerpc/lib/checksum_64.S | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/powerpc/lib/checksum_64.S b/arch/powerpc/lib/checksum_64.S
index 886ed94b9c13..2a68c43e13f5 100644
--- a/arch/powerpc/lib/checksum_64.S
+++ b/arch/powerpc/lib/checksum_64.S
@@ -443,6 +443,9 @@ _GLOBAL(csum_ipv6_magic)
addcr0, r8, r9
ld  r10, 0(r4)
ld  r11, 8(r4)
+#ifndef CONFIG_CPU_BIG_ENDIAN
+   rotldi  r5, r5, 8
+#endif
adder0, r0, r10
add r5, r5, r7
adder0, r0, r11
-- 
2.13.3



Re: [PATCH] powerpc: fix csum_ipv6_magic() on little endian platforms

2018-09-10 Thread Xin Long
On Mon, Sep 10, 2018 at 2:09 PM Christophe Leroy
 wrote:
>
> On little endian platforms, csum_ipv6_magic() keeps len and proto in
> CPU byte order. This generates a bad results leading to ICMPv6 packets
> from other hosts being dropped by powerpc64le platforms.
>
> In order to fix this, len and proto should be converted to network
> byte order ie bigendian byte order. However checksumming 0x12345678
> and 0x56341278 provide the exact same result so it is enough to
> rotate the sum of len and proto by 1 byte.
>
> PPC32 only support bigendian so the fix is needed for PPC64 only
>
> Fixes: e9c4943a107b ("powerpc: Implement csum_ipv6_magic in assembly")
> Reported-by: Jianlin Shi 
> Reported-by: Xin Long 
> Cc:  # 4.18+
> Signed-off-by: Christophe Leroy 
> ---
>  arch/powerpc/lib/checksum_64.S | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/arch/powerpc/lib/checksum_64.S b/arch/powerpc/lib/checksum_64.S
> index 886ed94b9c13..2a68c43e13f5 100644
> --- a/arch/powerpc/lib/checksum_64.S
> +++ b/arch/powerpc/lib/checksum_64.S
> @@ -443,6 +443,9 @@ _GLOBAL(csum_ipv6_magic)
> addcr0, r8, r9
> ld  r10, 0(r4)
> ld  r11, 8(r4)
> +#ifndef CONFIG_CPU_BIG_ENDIAN
> +   rotldi  r5, r5, 8
> +#endif
> adder0, r0, r10
> add r5, r5, r7
> adder0, r0, r11
> --
> 2.13.3
>
Tested-by: Xin Long 


Re: [PATCH] powerpc: fix csum_ipv6_magic() on little endian platforms

2018-09-17 Thread Christophe LEROY

Hi Michael,

Le 10/09/2018 à 16:28, Xin Long a écrit :

On Mon, Sep 10, 2018 at 2:09 PM Christophe Leroy
 wrote:


On little endian platforms, csum_ipv6_magic() keeps len and proto in
CPU byte order. This generates a bad results leading to ICMPv6 packets
from other hosts being dropped by powerpc64le platforms.

In order to fix this, len and proto should be converted to network
byte order ie bigendian byte order. However checksumming 0x12345678
and 0x56341278 provide the exact same result so it is enough to
rotate the sum of len and proto by 1 byte.

PPC32 only support bigendian so the fix is needed for PPC64 only

Fixes: e9c4943a107b ("powerpc: Implement csum_ipv6_magic in assembly")
Reported-by: Jianlin Shi 
Reported-by: Xin Long 
Cc:  # 4.18+
Signed-off-by: Christophe Leroy 
---
  arch/powerpc/lib/checksum_64.S | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/arch/powerpc/lib/checksum_64.S b/arch/powerpc/lib/checksum_64.S
index 886ed94b9c13..2a68c43e13f5 100644
--- a/arch/powerpc/lib/checksum_64.S
+++ b/arch/powerpc/lib/checksum_64.S
@@ -443,6 +443,9 @@ _GLOBAL(csum_ipv6_magic)
 addcr0, r8, r9
 ld  r10, 0(r4)
 ld  r11, 8(r4)
+#ifndef CONFIG_CPU_BIG_ENDIAN
+   rotldi  r5, r5, 8
+#endif
 adder0, r0, r10
 add r5, r5, r7
 adder0, r0, r11
--
2.13.3


Tested-by: Xin Long 



Could you take this fix for 4.19 ?

Unless someone takes it through the netdev tree ?

Thanks
Christophe