aboutsummaryrefslogtreecommitdiffstats
path: root/arch/um/kernel/trap_kern.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2006-03-31[PATCH] uml: sparse cleanupsAl Viro1-4/+4
misc sparse annotations Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-08[PATCH] uml: merge trap_user.c and trap_kern.cGennady Sharapov1-0/+14
The serial UML OS-abstraction layer patch (um/kernel dir). This joins trap_user.c and trap_kernel.c files. Signed-off-by: Gennady Sharapov <Gennady.V.Sharapov@intel.com> Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-08[PATCH] uml: move libc-dependent code from trap_user.cGennady Sharapov1-1/+10
The serial UML OS-abstraction layer patch (um/kernel dir). This moves all systemcalls from trap_user.c file under os-Linux dir Signed-off-by: Gennady Sharapov <Gennady.V.Sharapov@intel.com> Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-13[PATCH] uml: remove bogus WARN_ON, triggerable harmlessly on a page fault racePaolo 'Blaisorblade' Giarrusso1-0/+9
The below warning was added in place of pte_mkyoung(); if (is_write) pte_mkdirty(); In fact, if the PTE is not marked young/dirty, our dirty/accessed bit emulation would cause the TLB permission not to be changed, and so we'd loop, and given we don't support preemption yet, we'd busy-hang here. However, I've seen this warning trigger without crashes during a loop of concurrent kernel builds, at random times (i.e. like a race condition), and I realized that two concurrent faults on the same page, one on read and one on write, can trigger it. The read fault gets serviced and the PTE gets marked writable but clean (it's possible on a shared-writable mapping), while the generic code sees the PTE was already installed and returns without action. In this case, we'll see another fault and service it normally. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Acked-by: Jeff Dike <jdike@addtoit.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30[PATCH] uml: fix page faults in SKAS3 mode.Paolo 'Blaisorblade' Giarrusso1-1/+4
I hadn't been running a SKAS3 host when testing the "uml: fix hang in TT mode on fault" patch (commit 546fe1cbf91d4d62e3849517c31a2327c992e5c5), and I didn't think enough to the missing trap_no in SKAS3 mode. In fact, the resulting kernel doesn't work at all in SKAS3 mode. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-22[PATCH] uml: avoid fixing faults while atomicPaolo 'Blaisorblade' Giarrusso1-0/+7
Following i386, we should maybe refuse trying to fault in pages when we're doing atomic operations, because to handle the fault we could need to take already taken spinlocks. Also, if we're doing an atomic operation (in the sense of in_atomic()) we're surely in kernel mode and we're surely going to handle adequately the failed fault, so it's safe to behave this way. Currently, on UML SMP is rarely used, and we don't support PREEMPT, so this is unlikely to create problems right now, but it might in the future. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Cc: Jeff Dike <jdike@addtoit.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-22[PATCH] uml: fix hang in TT mode on faultPaolo 'Blaisorblade' Giarrusso1-1/+10
The current code doesn't handle well general protection faults on the host - it thinks that cr2 is always the address of a page fault. While actually, on general protection faults, that address is not accessible, so we'd better assume we couldn't satisfy the fault. Currently instead we think we've fixed it, so we go back, retry the instruction and fault again endlessly. This leads to the kernel hanging when doing copy_from_user(dest, -1, ...) in TT mode, since reading *(-1) causes a GFP, and we don't support kernel preemption. Thanks to Luo Xin for testing UML with LTP and reporting the failures he got. Cc: Luo Xin <luothing@sina.com> Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Cc: Jeff Dike <jdike@addtoit.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-10[PATCH] uml: avoid already done dirtyingPaolo 'Blaisorblade' Giarrusso1-2/+1
The PTE returned from handle_mm_fault is already marked as dirty and accessed if needed. Also, since this is not set with set_pte() (which sets NEWPAGE and NEWPROT as needed), this wouldn't work anyway. This version has been updated and fixed, thanks to some feedback from Jeff Dike. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-10[PATCH] uml: fix fault handler on writePaolo 'Blaisorblade' Giarrusso1-1/+2
The UML fault handler was recently changed to enforce PROT_NONE protections, by requiring VM_READ or VM_EXEC on VMA's. However, by mistake, things were changed such that VM_READ is always checked, also on write faults; so a VMA mapped with only PROT_WRITE is not readable (unless it's prefaulted with MAP_POPULATE or with a write), which is different from i386. Discovered while testing remap_file_pages protection support. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-05[PATCH] uml: fault handler micro-cleanupsPaolo 'Blaisorblade' Giarrusso1-15/+13
Avoid chomping low bits of address for functions doing it by themselves, fix whitespace, add a correctness checking. I did this for remap-file-pages protection support, it was useful on its own too. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Cc: Jeff Dike <jdike@addtoit.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-05[PATCH] uml: remove debugging code from page fault pathJeff Dike1-27/+0
This eliminates the segfault info ring buffer, which added a system call to each page fault, and which hadn't been useful for debugging in ages. Signed-off-by: Jeff Dike <jdike@addtoit.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-28[PATCH] uml: remove 2_5compat.hJeff Dike1-1/+0
Remove old useless header that was used in Ye Olde Times during 2.4->2.5 porting to abstract differences. It's definitions are no more used anyway, so let's finally kill it. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Jeff Dike <jdike@addtoit.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-20[PATCH] uml: Remove ubd-mmap supportJeff Dike1-29/+0
Finally rip out the ubd-mmap code, which turned out to be broken by design. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-20[PATCH] uml: Page fault fixesJeff Dike1-3/+4
Any access to a PROT_NONE page should segfault the process. A JVM seems to do this on purpose. Also, Al noticed some bogus code, which is now deleted. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-06[PATCH] uml: x86_64 fixesJeff Dike1-1/+1
This fixes some x86_64 bugs - - maybe_map returns -1 on error instead of 0, which is interpreted as physical address 0 - removed an include of ipc.h, which isn't needed - fixed the calculation of signal frame location - the signal delivery code is now immune to the stack expansion check - added a missing include Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-05[PATCH] uml: S390 preparation, abstract host page fault dataBodo Stroesser1-9/+16
This patch removes the arch-specific fault/trap-infos from thread and skas-regs. It adds a new struct faultinfo, that is arch-specific defined in sysdep/faultinfo.h. The structure is inserted in thread.arch and thread.regs.skas and thread.regs.tt Now, segv and other trap-handlers can copy the contents from regs.X.faultinfo to thread.arch.faultinfo with one simple assignment. Also, the number of macros necessary is reduced to FAULT_ADDRESS(struct faultinfo) extracts the faulting address from faultinfo FAULT_WRITE(struct faultinfo) extracts the "is_write" flag SEGV_IS_FIXABLE(struct faultinfo) is true for the fixable segvs, i.e. (TRAP == 14) on i386 UPT_FAULTINFO(regs) result is (struct faultinfo *) to the faultinfo in regs->skas.faultinfo GET_FAULTINFO_FROM_SC(struct faultinfo, struct sigcontext *) copies the relevant parts of the sigcontext to struct faultinfo. On SIGSEGV, call user_signal() instead of handle_segv(), if the architecture provides the information needed in PTRACE_FAULTINFO, or if PTRACE_FAULTINFO is missing, because segv-stub will provide the info. The benefit of the change is, that in case of a non-fixable SIGSEGV, we can give user processes a SIGSEGV, instead of possibly looping on pagefault handling. Since handle_segv() sikked arch_fixup() implicitly by passing ip==0 to segv(), I changed segv() to call arch_fixup() only, if !is_user. Signed-off-by: Bodo Stroesser <bstroesser@fujitsu-siemens.com> Signed-off-by: Jeff Dike <jdike@addtoit.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds1-0/+251
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!