Re: Bug in __copy_user

["Gleb O. Raiko" <raiko@niisi.msk.ru>]

Carsten Langgaard wrote:
> 
> I have started to look a little bit at the LTP tests.
> And one of the testcases that fails (actually it doesn't fail as it
> supposed to do) is the syscall getsockopt.
> I think the failure is due to the copy_to_user(0, from, 4) call returns
> 0, which I wouldn't expect when the destination pointer is NULL.
> 
> I think the problem is in the __copy_user function in
> arch/mips/lib/memcpy.
> It tries to handle the exception, which we get because the destination
> pointer is NULL, by returning the number of uncopied bytes in $a2 to the
> caller.
> But in this case the length is only 4 bytes, and the copying is done by
> a single 'sw'. The problem is the length ($a2) is decreased by 4 before
> the 'sw' is executed.
> The 'sw' fails and __copy_user terminates, but returns with $a2 = 0
> (instead 4).
> 
> I thing the following patch will solve the problem.

Been here, done that. In fact, I posted the following patch few days ago
to the list:
less_than_4units:
        /*
         * rem = len % NBYTES
         */
        beq     rem, len, copy_bytes
         nop
1:
EXC(    LOAD     t0, 0(src),            l_exc)
        ADD     src, src, NBYTES
        SUB     len, len, NBYTES
-EXC(    STORE   t0, 0(dst),             s_exc)
+EXC(    STORE   t0, 0(dst),             s_exc_p1u)
        bne     rem, len, 1b
         ADD    dst, dst, NBYTES

This patch also solves the problem for mips in 2.4/2.5 kernel. My
question was about the patch for mips64 and mips in 2.2 kernel.

Shall memcpy.S from 2.4/2.5 be backported to 2.2 and mips64?

Regards,
Gleb.