| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 63379c135331c724d40a87b98eb62d2122981341.
It broke userspace and adding more checking is not needed.
Even checking if a syscall would access memory in page zero doesn't
makes sense since it may lead to some syscalls returning -EFAULT
where we would return other error codes on other platforms.
In summary, just drop this change and return to always return 1.
Signed-off-by: Helge Deller <deller@gmx.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Up to now PA-RISC could live with a trivial version of access_ok().
Our fault handlers can correctly handle fault cases.
But testcases showed that we need a better access check else we won't
always return correct errno failure codes to userspace.
Problem showed up during 32bit userspace tests in which writev() used a
32bit memory area and length which would then wrap around on 64bit
kernel.
Signed-off-by: Helge Deller <deller@gmx.de>
|
| |
|
|
|
|
|
|
|
|
|
| |
Provide a macro ASM_EXCEPTIONTABLE_ENTRY() to create exception table
entries and convert all open-coded places to use that macro.
This patch is a first step toward creating a exception table which only
holds 32bit pointers even on a 64bit kernel. That way in my own kernel
I was able to reduce the in-kernel exception table from 44kB to 22kB.
Signed-off-by: Helge Deller <deller@gmx.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When targetting 32-bit processors, __put_user emits a pair of stw
instructions for the 8-byte case. If the type of __val is a pointer, the
marshalling code casts it to the wider integer type of u64, resulting
in the following compiler warnings:
kernel/signal.c: In function 'copy_siginfo_to_user':
kernel/signal.c:2752:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
kernel/signal.c:2752:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
[...]
This patch fixes the warnings by removing the marshalling code and using
the correct output modifiers in the __put_{user,kernel}_asm64 macros
so that GCC will allocate the right registers without the need to
extract the two words explicitly.
Cc: Helge Deller <deller@gmx.de>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
| |
|
|
| |
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
|
| |
|
|
|
|
|
| |
Disintegrate asm/system.h for PA-RISC.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-parisc@vger.kernel.org
|
| |
|
|
|
|
|
|
| |
Add CONFIG_DEBUG_STRICT_USER_COPY_CHECKS, copied from the x86
implementation. Tested with 32 and 64bit kernel.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The current asm-generic/page.h only contains the get_order
function, and asm-generic/uaccess.h only implements
unaligned accesses. This renames the file to getorder.h
and uaccess-unaligned.h to make room for new page.h
and uaccess.h file that will be usable by all simple
(e.g. nommu) architectures.
Signed-off-by: Remis Lima Baima <remis.developer@googlemail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
| |
|
|
|
|
|
|
|
| |
Fix those compile warnings:
uaccess.h:244: warning: `struct pt_regs' declared inside parameter list
uaccess.h:244: warning: its scope is only this definition or declaration, which is probably not what you want
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Wed, Dec 17, 2008 at 11:46:05PM +0100, Helge Deller wrote:
>
Honestly, I can't decide whether to apply this. It really should never
happen in the kernel, since the kernel can guarantee it won't get the
access rights failure (highest privilege level, and can set %sr and
%protid to whatever it wants.)
It really genuinely is a bug that probably should panic the kernel. The
only precedent I can easily see is x86 fixing up a bad iret with a
general protection fault, which is more or less analogous to code 27
here.
On the other hand, taking the exception on a userspace access really
isn't all that critical, and there's fundamentally little reason for the
kernel not to SIGSEGV the process, and continue...
Argh.
(btw, I've instrumented my do_sys_poll with a pile of assertions that
%cr8 << 1 == %sr3 == current->mm.context... let's see if where we're
getting corrupted is deterministic, though, I would guess that it won't
be.)
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
|
| |
|
