linux.git/mm/mlock.c, branch v2.6.31

mm: remove CONFIG_UNEVICTABLE_LRU config option

2009-06-17T02:47:42+00:00

Currently, nobody wants to turn UNEVICTABLE_LRU off.  Thus this
configurability is unnecessary.

Signed-off-by: KOSAKI Motohiro 
Cc: Johannes Weiner 
Cc: Andi Kleen 
Acked-by: Minchan Kim 
Cc: David Woodhouse 
Cc: Matt Mackall 
Cc: Rik van Riel 
Cc: Lee Schermerhorn 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

x86, bts, mm: clean up buffer allocation

2009-04-24T08:18:52+00:00

The current mm interface is asymetric. One function allocates a locked
buffer, another function only refunds the memory.

Change this to have two functions for accounting and refunding locked
memory, respectively; and do the actual buffer allocation in ptrace.

[ Impact: refactor BTS buffer allocation code ]

Signed-off-by: Markus Metzger 
Acked-by: Andrew Morton 
Cc: Peter Zijlstra 
LKML-Reference: <20090424095143.A30265@sedona.ch.intel.com>
Signed-off-by: Ingo Molnar

mm, x86, ptrace, bts: defer branch trace stopping, remove dead code

2009-04-08T08:57:24+00:00

Remove the unused free_locked_buffer() API.

Signed-off-by: Ingo Molnar

mm, x86, ptrace, bts: defer branch trace stopping

2009-04-07T11:36:13+00:00

When a ptraced task is unlinked, we need to stop branch tracing for
that task.

Since the unlink is called with interrupts disabled, and we need
interrupts enabled to stop branch tracing, we defer the work.

Collect all branch tracing related stuff in a branch tracing context.

Reviewed-by: Oleg Nesterov 
Signed-off-by: Markus Metzger 
Cc: Andrew Morton 
Cc: Peter Zijlstra 
Cc: roland@redhat.com
Cc: eranian@googlemail.com
Cc: juan.villacis@intel.com
Cc: ak@linux.jf.intel.com
LKML-Reference: <20090403144550.712401000@intel.com>
Signed-off-by: Ingo Molnar

Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

2009-02-17T22:27:39+00:00

* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  x86, vm86: fix preemption bug
  x86, olpc: fix model detection without OFW
  x86, hpet: fix for LS21 + HPET = boot hang
  x86: CPA avoid repeated lazy mmu flush
  x86: warn if arch_flush_lazy_mmu_cpu is called in preemptible context
  x86/paravirt: make arch_flush_lazy_mmu/cpu disable preemption
  x86, pat: fix warn_on_once() while mapping 0-1MB range with /dev/mem
  x86/cpa: make sure cpa is safe to call in lazy mmu mode
  x86, ptrace, mm: fix double-free on race

x86, ptrace, mm: fix double-free on race

2009-02-11T14:44:20+00:00

Ptrace_detach() races with __ptrace_unlink() if the traced task is
reaped while detaching. This might cause a double-free of the BTS
buffer.

Change the ptrace_detach() path to only do the memory accounting in
ptrace_bts_detach() and leave the buffer free to ptrace_bts_untrace()
which will be called from __ptrace_unlink().

The fix follows a proposal from Oleg Nesterov.

Reported-by: Oleg Nesterov 
Signed-off-by: Markus Metzger 
Signed-off-by: Ingo Molnar

mm: fix error case in mlock downgrade reversion

2009-02-08T21:53:28+00:00

Commit 27421e211a39784694b597dbf35848b88363c248, Manually revert
"mlock: downgrade mmap sem while populating mlocked regions", has
introduced its own regression: __mlock_vma_pages_range() may report
an error (for example, -EFAULT from trying to lock down pages from
beyond EOF), but mlock_vma_pages_range() must hide that from its
callers as before.

Reported-by: Sami Farin 
Signed-off-by: Hugh Dickins 
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds

Manually revert "mlock: downgrade mmap sem while populating mlocked regions"

2009-02-01T19:00:16+00:00

This essentially reverts commit 8edb08caf68184fb170f4f69c7445929e199eaea.

It downgraded our mmap semaphore to a read-lock while mlocking pages, in
order to allow other threads (and external accesses like "ps" et al) to
walk the vma lists and take page faults etc.  Which is a nice idea, but
the implementation does not work.

Because we cannot upgrade the lock back to a write lock without
releasing the mmap semaphore, the code had to release the lock entirely
and then re-take it as a writelock.  However, that meant that the caller
possibly lost the vma chain that it was following, since now another
thread could come in and mmap/munmap the range.

The code tried to work around that by just looking up the vma again and
erroring out if that happened, but quite frankly, that was just a buggy
hack that doesn't actually protect against anything (the other thread
could just have replaced the vma with another one instead of totally
unmapping it).

The only way to downgrade to a read map _reliably_ is to do it at the
end, which is likely the right thing to do: do all the 'vma' operations
with the write-lock held, then downgrade to a read after completing them
all, and then do the "populate the newly mlocked regions" while holding
just the read lock.  And then just drop the read-lock and return to user
space.

The (perhaps somewhat simpler) alternative is to just make all the
callers of mlock_vma_pages_range() know that the mmap lock got dropped,
and just re-grab the mmap semaphore if it needs to mlock more than one
vma region.

So we can do this "downgrade mmap sem while populating mlocked regions"
thing right, but the way it was done here was absolutely not correct.
Thus the revert, in the expectation that we will do it all correctly
some day.

Cc: Lee Schermerhorn 
Cc: Rik van Riel 
Cc: Andrew Morton 
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds

[CVE-2009-0029] System call wrappers part 14

2009-01-14T13:15:24+00:00

Signed-off-by: Heiko Carstens

[CVE-2009-0029] System call wrappers part 13

2009-01-14T13:15:23+00:00

Signed-off-by: Heiko Carstens