Subject: [PATCH] Fix TCP/UDP checksums on the Broadcom SB-1

From: Daniel Jacobowitz <[email-masked]>
Date: Mon, 19 Sep 2005 23:28:18 -0400

The type of sum in csum_tcpudp_nofold is "unsigned int", so when we assign
to it in an asm() block, and we're running on a system with 64-bit
registers, it is vitally important that we sign extend it correctly before
returning to C.  Otherwise the stray high bits will be preserved into
csum_fold, and on the SB-1 processor, 32-bit arithmetic on a non
sign-extended register will yield surprising results.

This caused incorrect checksums in some UDP packets for NFS root.  The
problem was mild when using a 10.0.1.x IP address, but severe when
using 192.168.1.x.

Signed-off-by: Daniel Jacobowitz <[email-masked]>

Index: linux/include/asm-mips/checksum.h
===================================================================
--- linux.orig/include/asm-mips/checksum.h	2005-09-19 21:00:48.000000000 -0400
+++ linux/include/asm-mips/checksum.h	2005-09-19 21:52:11.000000000 -0400
@@ -149,7 +149,7 @@ static inline unsigned int csum_tcpudp_n
 	"	daddu	%0, %4		\n"
 	"	dsll32	$1, %0, 0	\n"
 	"	daddu	%0, $1		\n"
-	"	dsrl32	%0, %0, 0	\n"
+	"	dsra32	%0, %0, 0	\n"
 #endif
 	"	.set	pop"
 	: "=r" (sum)

-- 
Daniel Jacobowitz
CodeSourcery, LLC

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 20 Sep 2005 11:43:27 +0100 (BST)

> problem was mild when using a 10.0.1.x IP address, but severe when

 Ah!  So *that* is the reason for the absolutely abysmal NFS performance 
of the SWARM with 2.6!  I have had no time to track it down -- thanks a 
lot!

  Maciej

---

From: Matej Kupljen <[email-masked]>
Date: Tue, 20 Sep 2005 13:00:04 +0200

Hi

> of the SWARM with 2.6!  I have had no time to track it down -- thanks a 

Is this for MIPS64 only?
Because, on dbau1200 we also have poor NFS performance :-(

BR,
Matej

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 20 Sep 2005 12:01:02 +0100

> problem was mild when using a 10.0.1.x IP address, but severe when

Good catch.  And just to increase the func factor this bug did also apply
to 2.4.  Applied,

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 20 Sep 2005 12:06:09 +0100

> Because, on dbau1200 we also have poor NFS performance :-(

It's for 64-bit kernels only.  Note the difference, I didn't say MIPS64.

Also, since this bug did result in an operation that has undefined
behaviour it likely may will only have impacted some 64-bit processors -
such as the SB1 - but others may have been unaffected.

  Ralf

---

From: "Michael Uhler" <[email-masked]>
Date: Tue, 20 Sep 2005 07:26:54 -0700

For what it's worth, the 64-bit architecture, both prior to and with MIPS64,
has always required that 64-bit GPRs be sign-extended when used with 32-bit
operations.  I'm surprised that this wasn't seen on more 64-bit CPUs than
just the SB1.

/gmu
---
Michael Uhler, Chief Technology Officer
MIPS Technologies, Inc.   Email: uhler at mips.com
1225 Charleston Road      Voice:  (650)567-5025
Mountain View, CA 94043

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ralf Baechle
> Sent: Tuesday, September 20, 2005 4:06 AM
> To: Matej Kupljen
> Cc: Maciej W. Rozycki; Daniel Jacobowitz; [email-masked]
> Subject: Re: [PATCH] Fix TCP/UDP checksums on the Broadcom SB-1
> 
> 
> > > > This caused incorrect checksums in some UDP packets for 
> NFS root.  
> > > > The problem was mild when using a 10.0.1.x IP address, 
> but severe 
> > > > when using 192.168.1.x.
> > > 
> Also, since this bug did result in an operation that has 
> undefined behaviour it likely may will only have impacted 
> some 64-bit processors - such as the SB1 - but others may 
> have been unaffected.
> 
>   Ralf
> 
>

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 20 Sep 2005 15:59:48 +0100

> operations.  I'm surprised that this wasn't seen on more 64-bit CPUs than

Usually resends will paper over this kind of problem.  It's only a question
of time until they succeed for any protocol that changed the packet
content sufficiently to make the checksum work eventually.  But of course
performance will suffer and as a matter of statistics certain IP address
and port ranges are going to suffer more than others.

  Ralf