Commit Graph

16 Commits

Author SHA1 Message Date
Gennady Sharapov
c66fdd5e32 [PATCH] uml: merge trap_user.c and trap_kern.c
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 20:13:39 -08:00
Gennady Sharapov
ea2ba7dc3d [PATCH] uml: move libc-dependent code from trap_user.c
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>
2006-01-08 20:13:39 -08:00
Paolo 'Blaisorblade' Giarrusso
cbc24afa82 [PATCH] uml: remove bogus WARN_ON, triggerable harmlessly on a page fault race
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-11-13 18:14:14 -08:00
Paolo 'Blaisorblade' Giarrusso
be662a18b7 [PATCH] uml: fix page faults in SKAS3 mode.
I hadn't been running a SKAS3 host when testing the "uml: fix hang in TT mode
on fault" patch (commit 546fe1cbf9), 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-30 12:41:18 -07:00
Paolo 'Blaisorblade' Giarrusso
fea03cb40a [PATCH] uml: avoid fixing faults while atomic
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 22:17:36 -07:00
Paolo 'Blaisorblade' Giarrusso
546fe1cbf9 [PATCH] uml: fix hang in TT mode on fault
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-22 22:17:36 -07:00
Paolo 'Blaisorblade' Giarrusso
16b036786a [PATCH] uml: avoid already done dirtying
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 12:00:18 -07:00
Paolo 'Blaisorblade' Giarrusso
d129f31236 [PATCH] uml: fix fault handler on write
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-10 12:00:18 -07:00
Paolo 'Blaisorblade' Giarrusso
3b52166cf7 [PATCH] uml: fault handler micro-cleanups
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 00:06:21 -07:00
Jeff Dike
96e59245e1 [PATCH] uml: remove debugging code from page fault path
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-09-05 00:06:19 -07:00
Jeff Dike
a2e4b972c9 [PATCH] uml: remove 2_5compat.h
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-28 16:46:11 -07:00
Jeff Dike
7b9014c1da [PATCH] uml: Remove ubd-mmap support
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 15:48:18 -07:00
Jeff Dike
13479d52c7 [PATCH] uml: Page fault fixes
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-20 15:48:17 -07:00
Jeff Dike
2d58cc9a43 [PATCH] uml: x86_64 fixes
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-06 22:09:31 -07:00
Bodo Stroesser
c578455a3e [PATCH] uml: S390 preparation, abstract host page fault data
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-05-05 16:36:36 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00