mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-05 03:16:39 +07:00
42a886af72
Most users by far do not care about the exact return value (they only
really care about whether the copy succeeded in its entirety or not),
but a few special core routines actually care deeply about exactly how
many bytes were copied from user space.
And the unrolled versions of the x86-64 user copy routines would
sometimes report that it had copied more bytes than it actually had.
Very few uses actually have partial copies to begin with, but to make
this bug even harder to trigger, most x86 CPU's use the "rep string"
instructions for normal user copies, and that version didn't have this
issue.
To make it even harder to hit, the one user of this that really cared
about the return value (and used the uncached version of the copy that
doesn't use the "rep string" instructions) was the generic write
routine, which pre-populated its source, once more hiding the problem by
avoiding the exception case that triggers the bug.
In other words, very special thanks to Bron Gondwana who not only
triggered this, but created a test-program to show it, and bisected the
behavior down to commit
|
||
|---|---|---|
| .. | ||
| checksum_32.S | ||
| clear_page_64.S | ||
| copy_page_64.S | ||
| copy_user_64.S | ||
| copy_user_nocache_64.S | ||
| csum-copy_64.S | ||
| csum-partial_64.c | ||
| csum-wrappers_64.c | ||
| delay_32.c | ||
| delay_64.c | ||
| getuser_32.S | ||
| getuser_64.S | ||
| io_64.c | ||
| iomap_copy_64.S | ||
| Makefile | ||
| memcpy_32.c | ||
| memcpy_64.S | ||
| memmove_64.c | ||
| memset_64.S | ||
| mmx_32.c | ||
| msr-on-cpu.c | ||
| putuser_32.S | ||
| putuser_64.S | ||
| rwlock_64.S | ||
| semaphore_32.S | ||
| string_32.c | ||
| strstr_32.c | ||
| thunk_64.S | ||
| usercopy_32.c | ||
| usercopy_64.c | ||