writev test failure related to arch/ppc/lib/string.S changes?

writev test failure related to arch/ppc/lib/string.S changes?

[Phil Estes]

Hi,
Recently I applied some 2.6.7 ppc32 patches to a 2.6.5 kernel, which
included the 1.1612.2.78 changeset titled "[PATCH] PPC32: Fix copy
prefetch on non coherent PPCs".  The functionality I meant to get from
that backport is working fine, but a test team which is testing my
changes note that a standard LTP testcase in the writev family now
fails, which they tracked to the changes made in arch/ppc/lib/string.S
from the above changeset.

Their comments follow:
> I checked the string.S of 2.6.7. I think there is a bug in it. 
> At 114, we set ctr=r0-r7. If exception occurs, it then goes to 104,
> then 92 where r3 is set to LG_CACHELINE_BYTES. Then it goes to 99.
>
> But in the remarks before 99, the number of bytes not copied is 
> r5 + (ctr << r3). This is not as what has happen because 
> ctr = r0 - r7. The ctr should be adjusted before it goes to 99.

The failing test being noted is the LTP writev02 test, which is 
an "expected to FAIL" testcase, but passes in this case.  A bad 
address is passed to writev, but instead of EFAULT, a positive 
integer is returned.  Again, backing out the above changeset 
causes this test (among a few other writev variants which expect 
failure) to pass accordingly.

Thanks for your help,
Phil Estes
pestes@us.ibm.com

Re: writev test failure related to arch/ppc/lib/string.S changes?

[Paul Mackerras]

Phil Estes writes:

> Recently I applied some 2.6.7 ppc32 patches to a 2.6.5 kernel, which
> included the 1.1612.2.78 changeset titled "[PATCH] PPC32: Fix copy
> prefetch on non coherent PPCs".  The functionality I meant to get from
> that backport is working fine, but a test team which is testing my
> changes note that a standard LTP testcase in the writev family now
> fails, which they tracked to the changes made in arch/ppc/lib/string.S
> from the above changeset.

Yeah.  This patch should fix it.  Mind testing it and letting us know
how it goes?

Paul.

diff -urN linux/arch/ppc/lib/string.S ppc/arch/ppc/lib/string.S
--- linux/arch/ppc/lib/string.S	2005-01-29 09:58:49.000000000 +1100
+++ ppc/arch/ppc/lib/string.S	2005-04-19 16:54:34.000000000 +1000
@@ -446,6 +446,7 @@
 #ifdef CONFIG_8xx
 	/* Don't use prefetch on 8xx */
 	mtctr	r0
+	li	r0,0
 53:	COPY_16_BYTES_WITHEX(0)
 	bdnz	53b
 
@@ -564,7 +565,9 @@
 /* or write fault in cacheline loop */
 105:	li	r9,1
 92:	li	r3,LG_CACHELINE_BYTES
-	b	99f
+	mfctr	r8
+	add	r0,r0,r8
+	b	106f
 /* read fault in final word loop */
 108:	li	r9,0
 	b	93f
@@ -585,7 +588,7 @@
  * r5 + (ctr << r3), and r9 is 0 for read or 1 for write.
  */
 99:	mfctr	r0
-	slw	r3,r0,r3
+106:	slw	r3,r0,r3
 	add.	r3,r3,r5
 	beq	120f			/* shouldn't happen */
 	cmpwi	0,r9,0

Re: writev test failure related to arch/ppc/lib/string.S changes?

[Phil Estes]

On Tue, 2005-04-19 at 19:47 +1000, Paul Mackerras wrote:

> Yeah.  This patch should fix it.  Mind testing it and letting us know
> how it goes?
> 
> Paul.
> 

Patch fixes the failure path--works great.  Thanks very much.

- Phil