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

[Phil Estes <pestes@us.ibm.com>]

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