aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/util/trace-event-scripting.c
diff options
context:
space:
mode:
authorHugh Dickins <[email protected]>2011-01-13 15:47:30 -0800
committerLinus Torvalds <[email protected]>2011-01-13 17:32:49 -0800
commit1ce82b69e96c838d007f316b8347b911fdfa9842 (patch)
treebe34e7c88a2544e620638834c8120b14b277d64a /tools/perf/util/trace-event-scripting.c
parent2919bfd0758257c469abef8c26c3e516bbebb851 (diff)
mm: fix migration hangs on anon_vma lock
Increased usage of page migration in mmotm reveals that the anon_vma locking in unmap_and_move() has been deficient since 2.6.36 (or even earlier). Review at the time of f18194275c39835cb84563500995e0d503a32d9a ("mm: fix hang on anon_vma->root->lock") missed the issue here: the anon_vma to which we get a reference may already have been freed back to its slab (it is in use when we check page_mapped, but that can change), and so its anon_vma->root may be switched at any moment by reuse in anon_vma_prepare. Perhaps we could fix that with a get_anon_vma_unless_zero(), but let's not: just rely on page_lock_anon_vma() to do all the hard thinking for us, then we don't need any rcu read locking over here. In removing the rcu_unlock label: since PageAnon is a bit in page->mapping, it's impossible for a !page->mapping page to be anon; but insert VM_BUG_ON in case the implementation ever changes. [[email protected]: coding-style fixes] Signed-off-by: Hugh Dickins <[email protected]> Reviewed-by: Mel Gorman <[email protected]> Reviewed-by: Rik van Riel <[email protected]> Cc: Naoya Horiguchi <[email protected]> Cc: "Jun'ichi Nomura" <[email protected]> Cc: Andi Kleen <[email protected]> Cc: <[email protected]> [2.6.37, 2.6.36] Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
Diffstat (limited to 'tools/perf/util/trace-event-scripting.c')
0 files changed, 0 insertions, 0 deletions