1. 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
  2. 08 5月, 2007 5 次提交
  3. 12 2月, 2007 2 次提交
  4. 16 10月, 2006 1 次提交
  5. 27 9月, 2006 1 次提交
  6. 26 9月, 2006 1 次提交
  7. 11 7月, 2006 2 次提交
  8. 06 6月, 2006 1 次提交
  9. 11 4月, 2006 1 次提交
  10. 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
  11. 02 2月, 2006 1 次提交
  12. 19 1月, 2006 1 次提交
  13. 09 1月, 2006 2 次提交
  14. 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
  15. 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