On 11/16/2013 10:44 PM, Linus Torvalds wrote:
> So this doesn't do the 32-bit truncation in the error path of the
> generic string copy. Oversight?
>
> Linus
I looked at the code again, and it turns out to be false alarm.
We *do* do 32-bit truncation in every path, still:
> ENTRY(copy_user_generic_string)
> CFI_STARTPROC
> ASM_STAC
> cmpl $8,%edx
> jb 2f /* less than 8 bytes, go to byte copy loop */
-> If we jump here, we will truncate at 2:
> ALIGN_DESTINATION
> movl %edx,%ecx
-> If we don't jb 2f we end up
> shrl $3,%ecx
32-bit truncation here...
> andl $7,%edx
> 1: rep
> movsq
> 2: movl %edx,%ecx
32-bit truncation here...
> 3: rep
> movsb
> xorl %eax,%eax
> ASM_CLAC
> ret
>
> .section .fixup,"ax"
> 11: lea (%rdx,%rcx,8),%rcx
> 12: movl %ecx,%edx /* ecx is zerorest also */
-> Even if %rdx+%rcx*8 > 2^32 we end up truncating at 12: -- not that it
matters, since both arguments are prototyped as "unsigned" and therefore
the C compiler is supposed to guarantee the upper 32 bits are ignored.
So I think Fenghua's patch is fine as-is.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
