| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bob Picco noted that 6edfba1b33c701108717f4e036320fc39abe1912
dropped the -ffreestanding compiler flag from the top level
Makefile, which allows the compiler to substitute memcpy() in
places where strcpy() is used with a known size source string.
But the ia64 memcpy() returns 0 for success, and "bytes copied"
for failure.
Fix to return the address of the destination string (like
stdlibc version, and other architectures). There are no
places where ia64 specific code makes use of the non-standard
return value.
Signed-off-by: Ken Chen <kenneth.w.chen@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The exception handler in copy user always expects fault occurs only on
user space address and the fall back recovery code is written with that
very assumption in mind. Recent source code inspection revealed that
while it worked splendid and to the expectation under normal circumstances,
It broke down under unexpected condition where some address calculation
might go outside the legal address range the original copy_user was
called for. This patch is to make copy_user exception handler more robust
and to prevent potential memory corruption.
Signed-off-by: Ken Chen <kenneth.w.chen@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
|
|
|
|
|
|
|
|
| |
The current ia64 assembler complains about mismatching .proc/.endp pairs.
(Same patch also sent by H.J. Lu)
Signed-off-by: Andreas Schwab <schwab@suse.de>
Signed-off-by: Tony Luck <tony.luck@intel.com>
|
|
|
|
|
|
|
|
|
|
|
| |
memcpy_mck.S::__copy_user breaks in the prefetch code under these conditions :-
* src is unaligned and
* dst is near the end of a page and
* the page after dst is unmapped.
Signed-off-by: Keith Owens <kaos@sgi.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|