summaryrefslogtreecommitdiffstats
path: root/mm/compaction.c
diff options
context:
space:
mode:
authorHugh Dickins <hughd@google.com>2012-10-08 16:29:07 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2012-10-09 16:22:20 +0900
commit6597d783397aebb793fb529474cce5089aa4c67f (patch)
tree059d7e4c18c8cec61a71a6c15994867dceb7b93a /mm/compaction.c
parentd741c9cdeee6a569dae0dbbaf028065402955b59 (diff)
downloadlinux-6597d783397aebb793fb529474cce5089aa4c67f.tar.gz
linux-6597d783397aebb793fb529474cce5089aa4c67f.tar.bz2
linux-6597d783397aebb793fb529474cce5089aa4c67f.zip
mm/mmap.c: replace find_vma_prepare() with clearer find_vma_links()
People get confused by find_vma_prepare(), because it doesn't care about what it returns in its output args, when its callers won't be interested. Clarify by passing in end-of-range address too, and returning failure if any existing vma overlaps the new range: instead of returning an ambiguous vma which most callers then must check. find_vma_links() is a clearer name. This does revert 2.6.27's dfe195fb79e88 ("mm: fix uninitialized variables for find_vma_prepare callers"), but it looks like gcc 4.3.0 was one of those releases too eager to shout about uninitialized variables: only copy_vma() warns with 4.5.1 and 4.7.1, which a BUG on error silences. [hughd@google.com: fix warning, remove BUG()] Signed-off-by: Hugh Dickins <hughd@google.com> Cc: Benny Halevy <bhalevy@tonian.com> Acked-by: Hillf Danton <dhillf@gmail.com> Signed-off-by: Hugh Dickins <hughd@google.com> Cc: David Rientjes <rientjes@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm/compaction.c')
0 files changed, 0 insertions, 0 deletions