1. 02 8月, 2012 1 次提交
  2. 25 3月, 2012 1 次提交
  3. 02 11月, 2011 1 次提交
  4. 23 10月, 2008 1 次提交
  5. 06 2月, 2008 5 次提交
    • J
      uml: get rid of syscall counters · a9b71b6c
      Jeff Dike 提交于
      Get rid of some syscall counters which haven't been useful in ages.
      Signed-off-by: NJeff Dike <jdike@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a9b71b6c
    • J
      uml: install panic notifier earlier · 0983a88b
      Jeff Dike 提交于
      It turns out that if there's a panic early enough, UML will just sit there in
      the LED-blinking loop because the panic notifier hadn't been installed yet.
      
      This patch installs it earlier.
      
      It also fixes the problem which exposed the hang, namely that if you give UML
      a zero-sized initrd, it will ask alloc_bootmem for zero bytes, and that will
      cause the panic.
      
      While I was in initrd.c, I gave it a style makeover.
      
      Prompted by checkpatch, I moved a couple extern declarations of uml_exitcode
      to kern_util.h.
      Signed-off-by: NJeff Dike <jdike@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0983a88b
    • J
      uml: kill processes instead of panicing kernel · 3e6f2ac4
      Jeff Dike 提交于
      UML was panicing in the case of failures of libc calls which shouldn't happen.
       This is an overreaction since a failure from libc doesn't normally mean that
      kernel data structures are in an unknown state.  Instead, the current process
      should just be killed if there is no way to recover.
      
      The case that prompted this was a failure of PTRACE_SETREGS restoring the same
      state that was read by PTRACE_GETREGS.  It appears that when a process tries
      to load a bogus value into a segment register, it segfaults (as expected) and
      the value is actually loaded and is seen by PTRACE_GETREGS (not expected).
      
      This case is fixed by forcing a fatal SIGSEGV on the process so that it
      immediately dies.  fatal_sigsegv was added for this purpose.  It was declared
      as noreturn, so in order to pursuade gcc that it actually does not return, I
      added a call to os_dump_core (and declared it noreturn) so that I get a core
      file if somehow the process survives.
      
      All other calls in arch/um/os-Linux/skas/process.c got the same treatment,
      with failures causing the process to die instead of a kernel panic, with some
      exceptions.
      
      userspace_tramp exits with status 1 if anything goes wrong there.  That will
      cause start_userspace to return an error.  copy_context_skas0 and
      map_stub_pages also now return errors instead of panicing.  Callers of thes
      functions were changed to check for errors and do something appropriate.
      Usually that's to return an error to their callers.
      check_skas3_ptrace_faultinfo just exits since that's too early to do anything
      else.
      
      save_registers, restore_registers, and init_registers now return status
      instead of panicing on failure, with their callers doing something
      appropriate.
      
      There were also duplicate declarations of save_registers and restore_registers
      in os.h - these are gone.
      
      I noticed and fixed up some whitespace damage.
      Signed-off-by: NJeff Dike <jdike@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3e6f2ac4
    • J
      uml: tidy kern_util.h · edea1385
      Jeff Dike 提交于
      Tidy kern_util.h.  It turns out that most of the function declarations
      aren't used, so they can go away.  os.h no longer includes
      kern_util.h, so files which got it through os.h now need to include it
      directly.  A number of other files never needed it, so these includes
      are deleted.
      
      The structure which was used to pass signal handlers from the kernel
      side to the userspace side is gone.  Instead, the handlers are
      declared here, and used directly from libc code.  This allows
      arch/um/os-Linux/trap.c to be deleted, with its remnants being moved
      to arch/um/os-Linux/skas/trap.c.
      
      arch/um/os-Linux/tty.c had its inclusions changed, and it needed some
      style attention, so it got tidied.
      Signed-off-by: NJeff Dike <jdike@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      edea1385
    • W
      uml: const and other tidying · c0a9290e
      WANG Cong 提交于
      This patch also does some improvements for uml code.  Improvements include
      dropping unnecessary cast, killing some unnecessary code and still some
      constifying for pointers etc..
      Signed-off-by: NWANG Cong <xiyou.wangcong@gmail.com>
      Signed-off-by: NJeff Dike <jdike@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c0a9290e
  6. 17 10月, 2007 5 次提交
    • J
      uml: eliminate hz() · 532d0fa4
      Jeff Dike 提交于
      Eliminate hz() since its only purpose was to provide a kernel-space constant
      to userspace code.  This can be done instead by providing the constant
      directly through kernel_constants.h.
      Signed-off-by: NJeff Dike <jdike@linux.intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      532d0fa4
    • J
      uml: style fixes pass 3 · ba180fd4
      Jeff Dike 提交于
      Formatting changes in the files which have been changed in the course
      of folding foo_skas functions into their callers.  These include:
      	copyright updates
      	header file trimming
      	style fixes
      	adding severity to printks
      
      These changes should be entirely non-functional.
      Signed-off-by: NJeff Dike <jdike@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ba180fd4
    • J
      uml: remove code made redundant by CHOOSE_MODE removal · 77bf4400
      Jeff Dike 提交于
      This patch makes a number of simplifications enabled by the removal of
      CHOOSE_MODE.  There were lots of functions that looked like
      
      	int foo(args){
      		foo_skas(args);
      	}
      
      The bodies of foo_skas are now folded into foo, and their declarations (and
      sometimes entire header files) are deleted.
      
      In addition, the union uml_pt_regs, which was a union between the tt and skas
      register formats, is now a struct, with the tt-mode arm of the union being
      removed.
      
      It turns out that usr2_handler was unused, so it is gone.
      Signed-off-by: NJeff Dike <jdike@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      77bf4400
    • J
      uml: throw out CONFIG_MODE_TT · 42fda663
      Jeff Dike 提交于
      This patchset throws out tt mode, which has been non-functional for a while.
      
      This is done in phases, interspersed with code cleanups on the affected files.
      
      The removal is done as follows:
      	remove all code, config options, and files which depend on
      CONFIG_MODE_TT
      	get rid of the CHOOSE_MODE macro, which decided whether to
      call tt-mode or skas-mode code, and replace invocations with their
      skas portions
      	replace all now-trivial procedures with their skas equivalents
      
      There are now a bunch of now-redundant pieces of data structures, including
      mode-specific pieces of the thread structure, pt_regs, and mm_context.  These
      are all replaced with their skas-specific contents.
      
      As part of the ongoing style compliance project, I made a style pass over all
      files that were changed.  There are three such patches, one for each phase,
      covering the files affected by that phase but no later ones.
      
      I noticed that we weren't freeing the LDT state associated with a process when
      it exited, so that's fixed in one of the later patches.
      
      The last patch is a tidying patch which I've had for a while, but which caused
      inexplicable crashes under tt mode.  Since that is no longer a problem, this
      can now go in.
      
      This patch:
      
      Start getting rid of tt mode support.
      
      This patch throws out CONFIG_MODE_TT and all config options, code, and files
      which depend on it.
      
      CONFIG_MODE_SKAS is gone and everything that depends on it is included
      unconditionally.
      
      The few changed lines are in re-written Kconfig help, lines which needed
      something skas-related removed from them, and a few more which weren't
      strictly deletions.
      Signed-off-by: NJeff Dike <jdike@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      42fda663
    • J
      uml: stop specially protecting kernel stacks · 5c8aacea
      Jeff Dike 提交于
      Map all of physical memory as executable to avoid having to change stack
      protections during fork and exit.
      
      unprotect_stack is now called only from MODE_TT code, so it is marked as such.
      Signed-off-by: NJeff Dike <jdike@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5c8aacea
  7. 20 9月, 2007 1 次提交
    • J
      uml: fix irqstack crash · 508a9274
      Jeff Dike 提交于
      This patch fixes a crash caused by an interrupt coming in when an IRQ stack
      is being torn down.  When this happens, handle_signal will loop, setting up
      the IRQ stack again because the tearing down had finished, and handling
      whatever signals had come in.
      
      However, to_irq_stack returns a mask of pending signals to be handled, plus
      bit zero is set if the IRQ stack was already active, and thus shouldn't be
      torn down.  This causes a problem because when handle_signal goes around
      the loop, sig will be zero, and to_irq_stack will duly set bit zero in the
      returned mask, faking handle_signal into believing that it shouldn't tear
      down the IRQ stack and return thread_info pointers back to their original
      values.
      
      This will eventually cause a crash, as the IRQ stack thread_info will
      continue pointing to the original task_struct and an interrupt will look
      into it after it has been freed.
      
      The fix is to stop passing a signal number into to_irq_stack.  Rather, the
      pending signals mask is initialized beforehand with the bit for sig already
      set.  References to sig in to_irq_stack can be replaced with references to
      the mask.
      
      [akpm@linux-foundation.org: use UL]
      Signed-off-by: NJeff Dike <jdike@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      508a9274
  8. 11 5月, 2007 1 次提交
    • J
      uml: iRQ stacks · c14b8494
      Jeff Dike 提交于
      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: NJeff Dike <jdike@linux.intel.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c14b8494
  9. 08 5月, 2007 5 次提交
  10. 12 2月, 2007 2 次提交
  11. 16 10月, 2006 1 次提交
  12. 27 9月, 2006 1 次提交
  13. 26 9月, 2006 1 次提交
  14. 11 7月, 2006 2 次提交
  15. 06 6月, 2006 1 次提交
  16. 11 4月, 2006 1 次提交
  17. 01 4月, 2006 1 次提交
    • P
      [PATCH] uml: clean arch_switch usage · 972410b0
      Paolo 'Blaisorblade' Giarrusso 提交于
      Call arch_switch also in switch_to_skas, even if it's, for now, a no-op for
      that case (and mark this in the comment); this will change soon.
      
      Also, arch_switch for TT mode is actually useless when the PT proxy (a
      complicate debugging instrumentation for TT mode) is not enabled.  In fact, it
      only calls update_debugregs, which checks debugregs_seq against seq (to check
      if the registers are up-to-date - seq here means a "version number" of the
      registers).
      
      If the ptrace proxy is not enabled, debugregs_seq always stays 0 and
      update_debugregs will be a no-op.  So, optimize this out (the compiler can't
      do it).
      
      Also, I've been disappointed by the fact that it would make a lot of sense if,
      after calling a successful
      update_debugregs(current->thread.arch.debugregs_seq),
      current->thread.arch.debugregs_seq were updated with the new debugregs_seq.
      But this is not done.  Is this a bug or a feature?  For all purposes, it seems
      a bug (otherwise the whole mechanism does not make sense, which is also a
      possibility to check), which causes some performance only problems (not
      correctness), since we write_debugregs when not needed.
      
      Also, as suggested by Jeff, remove a redundant enabling of SIGVTALRM,
      comprised in the subsequent local_irq_enable().  I'm just a bit dubious if
      ordering matters there...
      Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Acked-by: NJeff Dike <jdike@addtoit.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      972410b0
  18. 02 2月, 2006 1 次提交
  19. 19 1月, 2006 1 次提交
  20. 09 1月, 2006 2 次提交
  21. 06 5月, 2005 1 次提交
    • B
      [PATCH] uml: S390 preparation, abstract host page fault data · c578455a
      Bodo Stroesser 提交于
      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: NBodo Stroesser <bstroesser@fujitsu-siemens.com>
      Signed-off-by: NJeff Dike <jdike@addtoit.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c578455a
  22. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4