1. 04 2月, 2009 1 次提交
    • D
      sparc64: Kill bogus TPC/address truncation during 32-bit faults. · 9b026058
      David S. Miller 提交于
      This builds upon eeabac73
      ("sparc64: Validate kernel generated fault addresses on sparc64.")
      
      Upon further consideration, we actually should never see any
      fault addresses for 32-bit tasks with the upper 32-bits set.
      
      If it does every happen, by definition it's a bug.  Whatever
      context created that fault would only have that fault satisfied
      if we used the full 64-bit address.  If we truncate it, we'll
      always fault the wrong address and we'll always loop faulting
      forever.
      
      So catch such conditions and mark them as errors always.  Log
      the error and fail the fault.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9b026058
  2. 03 2月, 2009 1 次提交
    • D
      sparc64: Validate kernel generated fault addresses on sparc64. · eeabac73
      David S. Miller 提交于
      In order to handle all of the cases of address calculation overflow
      properly, we run sparc 32-bit processes in "address masking" mode
      when running on a 64-bit kernel.
      
      Address masking mode zeros out the top 32-bits of the address
      calculated for every load and store instruction.
      
      However, when we're in privileged mode we have to run with that
      address masking mode disabled even when accessing userspace from
      the kernel.
      
      To "simulate" the address masking mode we clear the top-bits by
      hand for 32-bit processes in the fault handler.
      
      It is the responsibility of code in the compat layer to properly
      zero extend addresses used to access userspace.  If this isn't
      followed properly we can get into a fault loop.
      
      Say that the user address is 0xf0000000 but for whatever reason
      the kernel code sign extends this to 64-bit, and then the kernel
      tries to access the result.
      
      In such a case we'll fault on address 0xfffffffff0000000 but the fault
      handler will process that fault as if it were to address 0xf0000000.
      We'll loop faulting forever because the fault never gets satisfied.
      
      So add a check specifically for this case, when the kernel is faulting
      on a user address access and the addresses don't match up.
      
      This code path is sufficiently slow path, and this bug is sufficiently
      painful to diagnose, that this kind of bug check is warranted.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eeabac73
  3. 05 12月, 2008 1 次提交
  4. 12 9月, 2008 1 次提交
  5. 18 7月, 2008 1 次提交
  6. 20 5月, 2008 1 次提交
  7. 29 2月, 2008 1 次提交
  8. 27 2月, 2008 1 次提交
    • D
      [SPARC64]: Loosen checks in exception table handling. · 622eaec6
      David S. Miller 提交于
      Some parts of the kernel now do things like do *_user() accesses while
      set_fs(KERNEL_DS) that fault on purpose.
      
      See, for example, the code added by changeset
      a0c1e907 ("futex: runtime enable pi
      and robust functionality").
      
      That trips up the ASI sanity checking we make in do_kernel_fault().
      
      Just remove it for now.  Maybe we can add it back later with an added
      conditional which looks at the current get_fs() value.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      622eaec6
  9. 17 10月, 2007 1 次提交
    • W
      During VM oom condition, kill all threads in process group · dcca2bde
      Will Schmidt 提交于
      We have had complaints where a threaded application is left in a bad state
      after one of it's threads is killed when we hit a VM: out_of_memory
      condition.
      
      Killing just one of the process threads can leave the application in a bad
      state, whereas killing the entire process group would allow for the
      application to restart, or be otherwise handled, and makes it very obvious
      that something has gone wrong.
      
      This change allows the entire process group to be taken down, rather
      than just the one thread.
      Signed-off-by: NWill Schmidt <will_schmidt@vnet.ibm.com>
      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: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Matthew Wilcox <willy@debian.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      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: Chris Zankel <chris@zankel.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dcca2bde
  10. 30 7月, 2007 1 次提交
  11. 20 7月, 2007 1 次提交
    • N
      mm: fault feedback #2 · 83c54070
      Nick Piggin 提交于
      This patch completes Linus's wish that the fault return codes be made into
      bit flags, which I agree makes everything nicer.  This requires requires
      all handle_mm_fault callers to be modified (possibly the modifications
      should go further and do things like fault accounting in handle_mm_fault --
      however that would be for another patch).
      
      [akpm@linux-foundation.org: fix alpha build]
      [akpm@linux-foundation.org: fix s390 build]
      [akpm@linux-foundation.org: fix sparc build]
      [akpm@linux-foundation.org: fix sparc64 build]
      [akpm@linux-foundation.org: fix ia64 build]
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      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: Bryan Wu <bryan.wu@analog.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Greg Ungerer <gerg@uclinux.org>
      Cc: Matthew Wilcox <willy@debian.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      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>
      Acked-by: NKyle McMartin <kyle@mcmartin.ca>
      Acked-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Acked-by: NAndi Kleen <ak@muc.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      [ Still apparently needs some ARM and PPC loving - Linus ]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      83c54070
  12. 09 5月, 2007 3 次提交
  13. 25 7月, 2006 1 次提交
  14. 27 6月, 2006 1 次提交
  15. 01 4月, 2006 1 次提交
  16. 27 3月, 2006 1 次提交
  17. 22 3月, 2006 1 次提交
  18. 20 3月, 2006 3 次提交
    • D
      [SPARC64]: Fix and re-enable dynamic TSB sizing. · 7a1ac526
      David S. Miller 提交于
      This is good for up to %50 performance improvement of some test cases.
      The problem has been the race conditions, and hopefully I've plugged
      them all up here.
      
      1) There was a serious race in switch_mm() wrt. lazy TLB
         switching to and from kernel threads.
      
         We could erroneously skip a tsb_context_switch() and thus
         use a stale TSB across a TSB grow event.
      
         There is a big comment now in that function describing
         exactly how it can happen.
      
      2) All code paths that do something with the TSB need to be
         guarded with the mm->context.lock spinlock.  This makes
         page table flushing paths properly synchronize with both
         TSB growing and TLB context changes.
      
      3) TSB growing events are moved to the end of successful fault
         processing.  Previously it was in update_mmu_cache() but
         that is deadlock prone.  At the end of do_sparc64_fault()
         we hold no spinlocks that could deadlock the TSB grow
         sequence.  We also have dropped the address space semaphore.
      
      While we're here, add prefetching to the copy_tsb() routine
      and put it in assembler into the tsb.S file.  This piece of
      code is quite time critical.
      
      There are some small negative side effects to this code which
      can be improved upon.  In particular we grab the mm->context.lock
      even for the tsb insert done by update_mmu_cache() now and that's
      a bit excessive.  We can get rid of that locking, and the same
      lock taking in flush_tsb_user(), by disabling PSTATE_IE around
      the whole operation including the capturing of the tsb pointer
      and tsb_nentries value.  That would work because anyone growing
      the TSB won't free up the old TSB until all cpus respond to the
      TSB change cross call.
      
      I'm not quite so confident in that optimization to put it in
      right now, but eventually we might be able to and the description
      is here for reference.
      
      This code seems very solid now.  It passes several parallel GCC
      bootstrap builds, and our favorite "nut cruncher" stress test which is
      a full "make -j8192" build of a "make allmodconfig" kernel.  That puts
      about 256 processes on each cpu's run queue, makes lots of process cpu
      migrations occur, causes lots of page table and TLB flushing activity,
      incurs many context version number changes, and it swaps the machine
      real far out to disk even though there is 16GB of ram on this test
      system. :-)
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7a1ac526
    • D
    • D
      [SPARC64]: Deal with PTE layout differences in SUN4V. · c4bce90e
      David S. Miller 提交于
      Yes, you heard it right, they changed the PTE layout for
      SUN4V.  Ho hum...
      
      This is the simple and inefficient way to support this.
      It'll get optimized, don't worry.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c4bce90e
  19. 10 11月, 2005 1 次提交
  20. 09 11月, 2005 1 次提交
  21. 29 9月, 2005 4 次提交
  22. 08 9月, 2005 1 次提交
  23. 11 7月, 2005 1 次提交
  24. 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