1. 10 8月, 2010 33 次提交
  2. 05 8月, 2010 1 次提交
    • J
      mm,kdb,kgdb: Add a debug reference for the kdb kmap usage · eac79005
      Jason Wessel 提交于
      The kdb kmap should never get used outside of the kernel debugger
      exception context.
      
      Signed-off-by: Jason Wessel<jason.wessel@windriver.com>
      CC: Andrew Morton <akpm@linux-foundation.org>
      CC: Ingo Molnar <mingo@elte.hu>
      CC: linux-mm@kvack.org
      eac79005
  3. 03 8月, 2010 2 次提交
  4. 01 8月, 2010 2 次提交
  5. 31 7月, 2010 1 次提交
    • H
      mm: fix ia64 crash when gcore reads gate area · de51257a
      Hugh Dickins 提交于
      Debian's ia64 autobuilders have been seeing kernel freeze or reboot
      when running the gdb testsuite (Debian bug 588574): dannf bisected to
      2.6.32 62eede62 "mm: ZERO_PAGE without
      PTE_SPECIAL"; and reproduced it with gdb's gcore on a simple target.
      
      I'd missed updating the gate_vma handling in __get_user_pages(): that
      happens to use vm_normal_page() (nowadays failing on the zero page),
      yet reported success even when it failed to get a page - boom when
      access_process_vm() tried to copy that to its intermediate buffer.
      
      Fix this, resisting cleanups: in particular, leave it for now reporting
      success when not asked to get any pages - very probably safe to change,
      but let's not risk it without testing exposure.
      
      Why did ia64 crash with 16kB pages, but succeed with 64kB pages?
      Because setup_gate() pads each 64kB of its gate area with zero pages.
      Reported-by: NAndreas Barth <aba@not.so.argh.org>
      Bisected-by: Ndann frazier <dannf@debian.org>
      Signed-off-by: NHugh Dickins <hughd@google.com>
      Tested-by: Ndann frazier <dannf@dannf.org>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      de51257a
  6. 29 7月, 2010 1 次提交
    • C
      slub numa: Fix rare allocation from unexpected node · bc6488e9
      Christoph Lameter 提交于
      The network developers have seen sporadic allocations resulting in objects
      coming from unexpected NUMA nodes despite asking for objects from a
      specific node.
      
      This is due to get_partial() calling get_any_partial() if partial
      slabs are exhausted for a node even if a node was specified and therefore
      one would expect allocations only from the specified node.
      
      get_any_partial() sporadically may return a slab from a foreign
      node to gradually reduce the size of partial lists on remote nodes
      and thereby reduce total memory use for a slab cache.
      
      The behavior is controlled by the remote_defrag_ratio of each cache.
      
      Strictly speaking this is permitted behavior since __GFP_THISNODE was
      not specified for the allocation but it is certain surprising.
      
      This patch makes sure that the remote defrag behavior only occurs
      if no node was specified.
      Signed-off-by: NChristoph Lameter <cl@linux-foundation.org>
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      bc6488e9