1. 05 5月, 2011 1 次提交
    • T
      slub: Fix the lockless code on 32-bit platforms with no 64-bit cmpxchg · 30106b8c
      Thomas Gleixner 提交于
      The SLUB allocator use of the cmpxchg_double logic was wrong: it
      actually needs the irq-safe one.
      
      That happens automatically when we use the native unlocked 'cmpxchg8b'
      instruction, but when compiling the kernel for older x86 CPUs that do
      not support that instruction, we fall back to the generic emulation
      code.
      
      And if you don't specify that you want the irq-safe version, the generic
      code ends up just open-coding the cmpxchg8b equivalent without any
      protection against interrupts or preemption.  Which definitely doesn't
      work for SLUB.
      
      This was reported by Werner Landgraf <w.landgraf@ru.ru>, who saw
      instability with his distro-kernel that was compiled to support pretty
      much everything under the sun.  Most big Linux distributions tend to
      compile for PPro and later, and would never have noticed this problem.
      
      This also fixes the prototypes for the irqsafe cmpxchg_double functions
      to use 'bool' like they should.
      
      [ Btw, that whole "generic code defaults to no protection" design just
        sounds stupid - if the code needs no protection, there is no reason to
        use "cmpxchg_double" to begin with.  So we should probably just remove
        the unprotected version entirely as pointless.   - Linus ]
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reported-and-tested-by: Nwerner <w.landgraf@ru.ru>
      Acked-and-tested-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NChristoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Tejun Heo <tj@kernel.org>
      Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1105041539050.3005@ionosSigned-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      30106b8c
  2. 29 4月, 2011 3 次提交
    • M
      mm: check if PTE is already allocated during page fault · cc03638d
      Mel Gorman 提交于
      With transparent hugepage support, handle_mm_fault() has to be careful
      that a normal PMD has been established before handling a PTE fault.  To
      achieve this, it used __pte_alloc() directly instead of pte_alloc_map as
      pte_alloc_map is unsafe to run against a huge PMD.  pte_offset_map() is
      called once it is known the PMD is safe.
      
      pte_alloc_map() is smart enough to check if a PTE is already present
      before calling __pte_alloc but this check was lost.  As a consequence,
      PTEs may be allocated unnecessarily and the page table lock taken.  Thi
      useless PTE does get cleaned up but it's a performance hit which is
      visible in page_test from aim9.
      
      This patch simply re-adds the check normally done by pte_alloc_map to
      check if the PTE needs to be allocated before taking the page table lock.
      The effect is noticable in page_test from aim9.
      
        AIM9
                        2.6.38-vanilla 2.6.38-checkptenone
        creat-clo      446.10 ( 0.00%)   424.47 (-5.10%)
        page_test       38.10 ( 0.00%)    42.04 ( 9.37%)
        brk_test        52.45 ( 0.00%)    51.57 (-1.71%)
        exec_test      382.00 ( 0.00%)   456.90 (16.39%)
        fork_test       60.11 ( 0.00%)    67.79 (11.34%)
        MMTests Statistics: duration
        Total Elapsed Time (seconds)                611.90    612.22
      
      (While this affects 2.6.38, it is a performance rather than a functional
      bug and normally outside the rules -stable.  While the big performance
      differences are to a microbench, the difference in fork and exec
      performance may be significant enough that -stable wants to consider the
      patch)
      Reported-by: NRaz Ben Yehuda <raziebe@gmail.com>
      Signed-off-by: NMel Gorman <mgorman@suse.de>
      Reviewed-by: NRik van Riel <riel@redhat.com>
      Reviewed-by: NAndrea Arcangeli <aarcange@redhat.com>
      Reviewed-by: NMinchan Kim <minchan.kim@gmail.com>
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Cc: <stable@kernel.org>		[2.6.38.x]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cc03638d
    • K
      oom: use pte pages in OOM score · f755a042
      KOSAKI Motohiro 提交于
      PTE pages eat up memory just like anything else, but we do not account for
      them in any way in the OOM scores.  They are also _guaranteed_ to get
      freed up when a process is OOM killed, while RSS is not.
      Reported-by: NDave Hansen <dave@linux.vnet.ibm.com>
      Signed-off-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Cc: <stable@kernel.org>		[2.6.36+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f755a042
    • A
      mm: thp: fix /dev/zero MAP_PRIVATE and vm_flags cleanups · 78f11a25
      Andrea Arcangeli 提交于
      The huge_memory.c THP page fault was allowed to run if vm_ops was null
      (which would succeed for /dev/zero MAP_PRIVATE, as the f_op->mmap wouldn't
      setup a special vma->vm_ops and it would fallback to regular anonymous
      memory) but other THP logics weren't fully activated for vmas with vm_file
      not NULL (/dev/zero has a not NULL vma->vm_file).
      
      So this removes the vm_file checks so that /dev/zero also can safely use
      THP (the other albeit safer approach to fix this bug would have been to
      prevent the THP initial page fault to run if vm_file was set).
      
      After removing the vm_file checks, this also makes huge_memory.c stricter
      in khugepaged for the DEBUG_VM=y case.  It doesn't replace the vm_file
      check with a is_pfn_mapping check (but it keeps checking for VM_PFNMAP
      under VM_BUG_ON) because for a is_cow_mapping() mapping VM_PFNMAP should
      only be allowed to exist before the first page fault, and in turn when
      vma->anon_vma is null (so preventing khugepaged registration).  So I tend
      to think the previous comment saying if vm_file was set, VM_PFNMAP might
      have been set and we could still be registered in khugepaged (despite
      anon_vma was not NULL to be registered in khugepaged) was too paranoid.
      The is_linear_pfn_mapping check is also I think superfluous (as described
      by comment) but under DEBUG_VM it is safe to stay.
      
      Addresses https://bugzilla.kernel.org/show_bug.cgi?id=33682Signed-off-by: NAndrea Arcangeli <aarcange@redhat.com>
      Reported-by: NCaspar Zhang <bugs@casparzhang.com>
      Acked-by: NMel Gorman <mel@csn.ul.ie>
      Acked-by: NRik van Riel <riel@redhat.com>
      Cc: <stable@kernel.org>		[2.6.38.x]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      78f11a25
  3. 15 4月, 2011 10 次提交
  4. 13 4月, 2011 2 次提交
    • L
      vm: fix vm_pgoff wrap in stack expansion · a626ca6a
      Linus Torvalds 提交于
      Commit 982134ba ("mm: avoid wrapping vm_pgoff in mremap()") fixed
      the case of a expanding mapping causing vm_pgoff wrapping when you used
      mremap.  But there was another case where we expand mappings hiding in
      plain sight: the automatic stack expansion.
      
      This fixes that case too.
      
      This one also found by Robert Święcki, using his nasty system call
      fuzzer tool.  Good job.
      Reported-and-tested-by: NRobert Święcki <robert@swiecki.net>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a626ca6a
    • L
      vm: fix mlock() on stack guard page · 95042f9e
      Linus Torvalds 提交于
      Commit 53a7706d ("mlock: do not hold mmap_sem for extended periods
      of time") changed mlock() to care about the exact number of pages that
      __get_user_pages() had brought it.  Before, it would only care about
      errors.
      
      And that doesn't work, because we also handled one page specially in
      __mlock_vma_pages_range(), namely the stack guard page.  So when that
      case was handled, the number of pages that the function returned was off
      by one.  In particular, it could be zero, and then the caller would end
      up not making any progress at all.
      
      Rather than try to fix up that off-by-one error for the mlock case
      specially, this just moves the logic to handle the stack guard page
      into__get_user_pages() itself, thus making all the counts come out
      right automatically.
      Reported-by: NRobert Święcki <robert@swiecki.net>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      95042f9e
  5. 07 4月, 2011 1 次提交
  6. 31 3月, 2011 1 次提交
  7. 29 3月, 2011 1 次提交
  8. 28 3月, 2011 2 次提交
    • D
      NOMMU: percpu should use is_vmalloc_addr(). · eac522ef
      David Howells 提交于
      per_cpu_ptr_to_phys() uses VMALLOC_START and VMALLOC_END to determine if an
      address is in the vmalloc() region or not.  This is incorrect on NOMMU as
      there is no real vmalloc() capability (vmalloc() is emulated by kmalloc()).
      
      The correct way to do this is to use is_vmalloc_addr().  This encapsulates the
      vmalloc() region test in MMU mode and just returns 0 in NOMMU mode.
      
      On FRV in NOMMU mode, the percpu compilation fails without this patch:
      
      mm/percpu.c: In function 'per_cpu_ptr_to_phys':
      mm/percpu.c:1011: error: 'VMALLOC_START' undeclared (first use in this function)
      mm/percpu.c:1011: error: (Each undeclared identifier is reported only once
      mm/percpu.c:1011: error: for each function it appears in.)
      mm/percpu.c:1012: error: 'VMALLOC_END' undeclared (first use in this function)
      mm/percpu.c:1018: warning: control reaches end of non-void function
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      eac522ef
    • R
      mm: fix memory.c incorrect kernel-doc · ae91dbfc
      Randy Dunlap 提交于
      Fix mm/memory.c incorrect kernel-doc function notation:
      
        Warning(mm/memory.c:3718): Cannot understand  * @access_remote_vm - access another process' address space
         on line 3718 - I thought it was a doc line
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ae91dbfc
  9. 25 3月, 2011 5 次提交
  10. 24 3月, 2011 14 次提交
反馈
建议
客服 返回
顶部