1. 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
  2. 02 2月, 2006 1 次提交
  3. 19 1月, 2006 1 次提交
  4. 09 1月, 2006 2 次提交
  5. 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
  6. 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