1
Commit Graph

18 Commits

Author SHA1 Message Date
Jeff Dike
c14b84949e uml: iRQ stacks
Add a separate IRQ stack.  This differs from i386 in having the entire
interrupt run on a separate stack rather than starting on the normal kernel
stack and switching over once some preparation has been done.  The underlying
mechanism, is of course, sigaltstack.

Another difference is that interrupts that happen in userspace are handled on
the normal kernel stack.  These cause a wait wakeup instead of a signal
delivery so there is no point in trying to switch stacks for these.  There's
no other stuff on the stack, so there is no extra stack consumption.

This quirk makes it possible to have the entire interrupt run on a separate
stack - process preemption (and calls to schedule()) happens on a normal
kernel stack.  If we enable CONFIG_PREEMPT, this will need to be rethought.

The IRQ stack for CPU 0 is declared in the same way as the initial kernel
stack.  IRQ stacks for other CPUs will be allocated dynamically.

An extra field was added to the thread_info structure.  When the active
thread_info is copied to the IRQ stack, the real_thread field points back to
the original stack.  This makes it easy to tell where to copy the thread_info
struct back to when the interrupt is finished.  It also serves as a marker of
a nested interrupt.  It is NULL for the first interrupt on the stack, and
non-NULL for any nested interrupts.

Care is taken to behave correctly if a second interrupt comes in when the
thread_info structure is being set up or taken down.  I could just disable
interrupts here, but I don't feel like giving up any of the performance gained
by not flipping signals on and off.

If an interrupt comes in during these critical periods, the handler can't run
because it has no idea what shape the stack is in.  So, it sets a bit for its
signal in a global mask and returns.  The outer handler will deal with this
signal itself.

Atomicity is had with xchg.  A nested interrupt that needs to bail out will
xchg its signal mask into pending_mask and repeat in case yet another
interrupt hit at the same time, until the mask stabilizes.

The outermost interrupt will set up the thread_info and xchg a zero into
pending_mask when it is done.  At this point, nested interrupts will look at
->real_thread and see that no setup needs to be done.  They can just continue
normally.

Similar care needs to be taken when exiting the outer handler.  If another
interrupt comes in while it is copying the thread_info, it will drop a bit
into pending_mask.  The outer handler will check this and if it is non-zero,
will loop, set up the stack again, and handle the interrupt.

Signed-off-by: Jeff Dike <jdike@linux.intel.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-11 08:29:34 -07:00
Jeff Dike
9218b17149 uml: remove user_util.h
user_util.h isn't needed any more, so delete it and remove all includes of it.

Signed-off-by: Jeff Dike <jdike@linux.intel.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-07 12:13:01 -07:00
Jeff Dike
24fa6c0832 uml: move remaining useful contents of user_util.h
Rescue the useful contents of the soon-to-be-gone user-util.h.

pty.c now gets ptsname from stdlib.h like it should have always done.

CATCH_EINTR is now in os.h, although perhaps all usage should be under
os-Linux at some point.

get_pty is also in os.h.

This patch restores the old definition of ARRAY_SIZE in user.h.  This file is
included only in userspace files, so there will be no conflict with the
kernel's new ARRAY_SIZE.  The copy of the kernel's ARRAY_SIZE and associated
infrastructure is now gone.

Signed-off-by: Jeff Dike <jdike@linux.intel.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-07 12:13:01 -07:00
Jeff Dike
b92c4f922b [PATCH] uml: use correct register file size everywhere
This patch uses MAX_REG_NR consistently to refer to the register file size.
 FRAME_SIZE isn't sufficient because on x86_64, it is smaller than the
ptrace register file size.  MAX_REG_NR was introduced as a consistent way
to get the number of registers, but wasn't used everywhere it should be.

When this causes a problem, it makes PTRACE_SETREGS fail on x86_64 because
of a corrupted segment register value in the known-good register file.  The
patch also adds a register dump at that point in case there are any future
problems here.

Signed-off-by: Jeff Dike <jdike@linux.intel.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-03-27 09:05:15 -07:00
Jeff Dike
6c59e2f593 [PATCH] uml: register handling formatting fixes
Formatting fixes in the register handling code.

Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-11 10:51:24 -08:00
Paolo 'Blaisorblade' Giarrusso
b428b51ed9 [PATCH] Fix "Remove the use of _syscallX macros in UML"
Fix commit 5f4c6bc1f3: it spits out warnings
about missing syscall prototype (it is in <unistd.h>) and it does not
recognize that two uses of _syscallX are to be resolved against kernel
headers in the source tree, not against _syscallX; they in fact do not
compile and would not work anyway.

If _syscallX macros will be removed from the kernel tree altogether, the
only reasonable solution for that piece of code is switching to open-coded
inline assembly (it's remapping the whole executable from memory, except
the page containing this code).

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>
2006-10-30 12:08:41 -08:00
Arnd Bergmann
5f4c6bc1f3 [PATCH] Remove the use of _syscallX macros in UML
User mode linux uses _syscallX() to call into the host kernel.  The
recommended way to do this is to use the syscall() function from libc.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andi Kleen <ak@muc.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Ian Molton <spyro@f2s.com>
Cc: Mikael Starvik <starvik@axis.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Hirokazu Takata <takata.hirokazu@renesas.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp>
Cc: Richard Curnow <rc@rc0.org.uk>
Cc: William Lee Irwin III <wli@holomorphy.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Cc: Miles Bader <uclinux-v850@lsi.nec.co.jp>
Cc: Chris Zankel <chris@zankel.net>
Cc: "Luck, Tony" <tony.luck@intel.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-02 07:57:23 -07:00
Jeff Dike
75e29b18d9 [PATCH] uml: stack usage reduction
The KSTK_* macros used an inordinate amount of stack.  In order to overcome
an impedance mismatch between their interface, which just returns a single
register value, and the interface of get_thread_regs, which took a full
pt_regs, the implementation created an on-stack pt_regs, filled it in, and
returned one field.  do_task_stat calls KSTK_* twice, resulting in two
local pt_regs, blowing out the stack.

This patch changes the interface (and name) of get_thread_regs to just
return a single register from a jmp_buf.

The include of archsetjmp.h" in registers.h to get the definition of
jmp_buf exposed a bogus include of <setjmp.h> in start_up.c.  <setjmp.h>
shouldn't be used anywhere any more since UML uses the klibc
setjmp/longjmp.

Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-09-26 08:49:09 -07:00
Jeff Dike
4b84c69b5f [PATCH] uml: Move signal handlers to arch code
Have most signals go through an arch-provided handler which recovers the
sigcontext and then calls a generic handler.  This replaces the
ARCH_GET_SIGCONTEXT macro, which was somewhat fragile.  On x86_64, recovering
%rdx (which holds the sigcontext pointer) must be the first thing that
happens.  sig_handler duly invokes that first, but there is no guarantee that
I can see that instructions won't be reordered such that %rdx is used before
that.  Having the arch provide the handler seems much more robust.

Some signals in some parts of UML require their own handlers - these places
don't call set_handler any more.  They call sigaction or signal themselves.

Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-09-26 08:49:07 -07:00
Jeff Dike
13c06be399 [PATCH] uml: Use klibc setjmp/longjmp
This patch adds an implementation of setjmp and longjmp to UML, allowing
access to the inside of a jmpbuf without needing the access macros formerly
provided by libc.

The implementation is stolen from klibc.  I copy the relevant files into
arch/um.  I have another patch which avoids the copying, but requires klibc be
in the tree.

setjmp and longjmp users required some tweaking.  Includes of <setjmp.h> were
removed and includes of the UML longjmp.h were added where necessary.  There
are also replacements of siglongjmp with UML_LONGJMP which I somehow missed
earlier.

Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-09-26 08:49:05 -07:00
Jeff Dike
2ace87b950 [PATCH] uml: error handling fixes
Blairsorblade noticed some confusion between our use of a system
call's return value and errno.  This patch fixes a number of related
bugs -
	using errno instead of a return value
	using a return value instead of errno
	forgetting to negate a error return to get a positive error code

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-05-01 18:17:44 -07:00
Jeff Dike
a5d2f46a97 [PATCH] UML: TLS fixlets
Two small TLS fixes -

arch/um/os-Linux/sys-i386/tls.c uses errno and -E* so it should include
    errno.h
__setup_host_supports_tls returns 1, but as an initcall, it should return 0

Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-11 06:18:35 -07:00
Paolo 'Blaisorblade' Giarrusso
3feb88562d [PATCH] uml: check for differences in host support
If running on a host not supporting TLS (for instance 2.4) we should report
that cleanly to the user, instead of printing not comprehensible "error 5" for
that.

Additionally, i386 and x86_64 support different ranges for
user_desc->entry_number, and we must account for that; we couldn't pass
ourselves -1 because we need to override previously existing TLS descriptors
which glibc has possibly set, so test at startup the range to use.

x86 and x86_64 existing ranges are hardcoded.

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>
2006-03-31 12:18:52 -08:00
Jeff Dike
e2216feb37 [PATCH] uml: initialize process FP registers properly
We weren't making sure that we initialized the FP registers of new processes
to sane values.

This patch also moves some defines in the affected area closer to where they
are used.

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-02-07 16:12:32 -08:00
Allan Graves
fad1c45c93 [PATCH] uml: Fix sysrq-r support for skas mode
The old code had the IP and SP coming from the registers in the thread
struct, which are completely wrong since those are the userspace
registers.  This fixes that by pulling the correct values from the
jmp_buf in which the kernel state of each thread is stored.

Signed-off-by: Allan Graves <allan.graves@oracle.com>
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-04 13:22:01 -07:00
Jeff Dike
d67b569f5f [PATCH] uml: skas0 - separate kernel address space on stock hosts
UML has had two modes of operation - an insecure, slow mode (tt mode) in
which the kernel is mapped into every process address space which requires
no host kernel modifications, and a secure, faster mode (skas mode) in
which the UML kernel is in a separate host address space, which requires a
patch to the host kernel.

This patch implements something very close to skas mode for hosts which
don't support skas - I'm calling this skas0.  It provides the security of
the skas host patch, and some of the performance gains.

The two main things that are provided by the skas patch, /proc/mm and
PTRACE_FAULTINFO, are implemented in a way that require no host patch.

For the remote address space changing stuff (mmap, munmap, and mprotect),
we set aside two pages in the process above its stack, one of which
contains a little bit of code which can call mmap et al.

To update the address space, the system call information (system call
number and arguments) are written to the stub page above the code.  The
%esp is set to the beginning of the data, the %eip is set the the start of
the stub, and it repeatedly pops the information into its registers and
makes the system call until it sees a system call number of zero.  This is
to amortize the cost of the context switch across multiple address space
updates.

When the updates are done, it SIGSTOPs itself, and the kernel process
continues what it was doing.

For a PTRACE_FAULTINFO replacement, we set up a SIGSEGV handler in the
child, and let it handle segfaults rather than nullifying them.  The
handler is in the same page as the mmap stub.  The second page is used as
the stack.  The handler reads cr2 and err from the sigcontext, sticks them
at the base of the stack in a faultinfo struct, and SIGSTOPs itself.  The
kernel then reads the faultinfo and handles the fault.

A complication on x86_64 is that this involves resetting the registers to
the segfault values when the process is inside the kill system call.  This
breaks on x86_64 because %rcx will contain %rip because you tell SYSRET
where to return to by putting the value in %rcx.  So, this corrupts $rcx on
return from the segfault.  To work around this, I added an
arch_finish_segv, which on x86 does nothing, but which on x86_64 ptraces
the child back through the sigreturn.  This causes %rcx to be restored by
sigreturn and avoids the corruption.  Ultimately, I think I will replace
this with the trick of having it send itself a blocked signal which will be
unblocked by the sigreturn.  This will allow it to be stopped just after
the sigreturn, and PTRACE_SYSCALLed without all the back-and-forth of
PTRACE_SYSCALLing it through sigreturn.

This runs on a stock host, so theoretically (and hopefully), tt mode isn't
needed any more.  We need to make sure that this is better in every way
than tt mode, though.  I'm concerned about the speed of address space
updates and page fault handling, since they involve extra round-trips to
the child.  We can amortize the round-trip cost for large address space
updates by writing all of the operations to the data page and having the
child execute them all at the same time.  This will help fork and exec, but
not page faults, since they involve only one page.

I can't think of any way to help page faults, except to add something like
PTRACE_FAULTINFO to the host.  There is PTRACE_SIGINFO, but UML doesn't use
siginfo for SIGSEGV (or anything else) because there isn't enough
information in the siginfo struct to handle page faults (the faulting
operation type is missing).  Adding that would make PTRACE_SIGINFO a usable
equivalent to PTRACE_FAULTINFO.

As for the code itself:

- The system call stub is in arch/um/kernel/sys-$(SUBARCH)/stub.S.  It is
  put in its own section of the binary along with stub_segv_handler in
  arch/um/kernel/skas/process.c.  This is manipulated with run_syscall_stub
  in arch/um/kernel/skas/mem_user.c.  syscall_stub will execute any system
  call at all, but it's only used for mmap, munmap, and mprotect.

- The x86_64 stub calls sigreturn by hand rather than allowing the normal
  sigreturn to happen, because the normal sigreturn is a SA_RESTORER in
  UML's address space provided by libc.  Needless to say, this is not
  available in the child's address space.  Also, it does a couple of odd
  pops before that which restore the stack to the state it was in at the
  time the signal handler was called.

- There is a new field in the arch mmu_context, which is now a union.
  This is the pid to be manipulated rather than the /proc/mm file
  descriptor.  Code which deals with this now checks proc_mm to see whether
  it should use the usual skas code or the new code.

- userspace_tramp is now used to create a new host process for every UML
  process, rather than one per UML processor.  It checks proc_mm and
  ptrace_faultinfo to decide whether to map in the pages above its stack.

- start_userspace now makes CLONE_VM conditional on proc_mm since we need
  separate address spaces now.

- switch_mm_skas now just sets userspace_pid[0] to the new pid rather
  than PTRACE_SWITCH_MM.  There is an addition to userspace which updates
  its idea of the pid being manipulated each time around the loop.  This is
  important on exec, when the pid will change underneath userspace().

- The stub page has a pte, but it can't be mapped in using tlb_flush
  because it is part of tlb_flush.  This is why it's required for it to be
  mapped in by userspace_tramp.

Other random things:

- The stub section in uml.lds.S is page aligned.  This page is written
  out to the backing vm file in setup_physmem because it is mapped from
  there into user processes.

- There's some confusion with TASK_SIZE now that there are a couple of
  extra pages that the process can't use.  TASK_SIZE is considered by the
  elf code to be the usable process memory, which is reasonable, so it is
  decreased by two pages.  This confuses the definition of
  USER_PGDS_IN_LAST_PML4, making it too small because of the rounding down
  of the uneven division.  So we round it to the nearest PGDIR_SIZE rather
  than the lower one.

- I added a missing PT_SYSCALL_ARG6_OFFSET macro.

- um_mmu.h was made into a userspace-usable file.

- proc_mm and ptrace_faultinfo are globals which say whether the host
  supports these features.

- There is a bad interaction between the mm.nr_ptes check at the end of
  exit_mmap, stack randomization, and skas0.  exit_mmap will stop freeing
  pages at the PGDIR_SIZE boundary after the last vma.  If the stack isn't
  on the last page table page, the last pte page won't be freed, as it
  should be since the stub ptes are there, and exit_mmap will BUG because
  there is an unfreed page.  To get around this, TASK_SIZE is set to the
  next lowest PGDIR_SIZE boundary and mm->nr_ptes is decremented after the
  calls to init_stub_pte.  This ensures that we know the process stack (and
  all other process mappings) will be below the top page table page, and
  thus we know that mm->nr_ptes will be one too many, and can be
  decremented.

Things that need fixing:

- We may need better assurrences that the stub code is PIC.

- The stub pte is set up in init_new_context_skas.

- alloc_pgdir is probably the right place.

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-07-07 18:23:44 -07:00
Andree Leidenfrost
6aec307283 [PATCH] uml: fix handling of no fpx_regs
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>

Fix the error path, which is triggered when the processor misses the fpx
regs (i.e.  the "fxsr" cpuinfo feature).  For instance by VIA C3 Samuel2.

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-05-01 08:58:53 -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