mm: remove call to find_vma in pagewalk for non-hugetlbfs
David Sterba [Wed, 24 Nov 2010 20:57:10 +0000 (12:57 -0800)]
Commit d33b9f45 ("mm: hugetlb: fix hugepage memory leak in
walk_page_range()") introduces a check if a vma is a hugetlbfs one and
later in 5dc37642 ("mm hugetlb: add hugepage support to pagemap") it is
moved under #ifdef CONFIG_HUGETLB_PAGE but a needless find_vma call is
left behind and its result is not used anywhere else in the function.

The side-effect of caching vma for @addr inside walk->mm is neither
utilized in walk_page_range() nor in called functions.

Signed-off-by: David Sterba <>
Reviewed-by: Naoya Horiguchi <>
Acked-by: Andi Kleen <>
Cc: Andy Whitcroft <>
Cc: David Rientjes <>
Cc: Hugh Dickins <>
Cc: Lee Schermerhorn <>
Cc: Matt Mackall <>
Acked-by: Mel Gorman <>
Cc: Wu Fengguang <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>


index 8b1a2ce..38cc58b 100644 (file)
@@ -139,7 +139,6 @@ int walk_page_range(unsigned long addr, unsigned long end,
        pgd_t *pgd;
        unsigned long next;
        int err = 0;
-       struct vm_area_struct *vma;
        if (addr >= end)
                return err;
@@ -149,15 +148,17 @@ int walk_page_range(unsigned long addr, unsigned long end,
        pgd = pgd_offset(walk->mm, addr);
        do {
+               struct vm_area_struct *uninitialized_var(vma);
                next = pgd_addr_end(addr, end);
                 * handle hugetlb vma individually because pagetable walk for
                 * the hugetlb page is dependent on the architecture and
                 * we can't handled it in the same manner as non-huge pages.
                vma = find_vma(walk->mm, addr);
                if (vma && is_vm_hugetlb_page(vma)) {
                        if (vma->vm_end < next)
                                next = vma->vm_end;