aboutsummaryrefslogtreecommitdiffstats
path: root/arch/i386
diff options
context:
space:
mode:
authorDavid Gibson <david@gibson.dropbear.id.au>2006-03-22 00:08:58 -0800
committerLinus Torvalds <torvalds@g5.osdl.org>2006-03-22 07:54:04 -0800
commit4866920b93fd7d5b520278c3c76e6f4d5a352d81 (patch)
treec4b8642c83e11af6d8e57ab35dc479f2c1a651d0 /arch/i386
parent[PATCH] hugepage: Fix hugepage logic in free_pgtables() (diff)
downloadlinux-dev-4866920b93fd7d5b520278c3c76e6f4d5a352d81.tar.xz
linux-dev-4866920b93fd7d5b520278c3c76e6f4d5a352d81.zip
[PATCH] hugepage: Fix hugepage logic in free_pgtables() harder
Turns out the hugepage logic in free_pgtables() was doubly broken. The loop coalescing multiple normal page VMAs into one call to free_pgd_range() had an off by one error, which could mean it would coalesce one hugepage VMA into the same bundle (checking 'vma' not 'next' in the loop). I transferred this bug into the new is_vm_hugetlb_page() based version. Here's the fix. This one didn't bite on powerpc previously for the same reason the is_hugepage_only_range() problem didn't: powerpc's hugetlb_free_pgd_range() is identical to free_pgd_range(). It didn't bite on ia64 because the hugepage region is distant enough from any other region that the separated PMD_SIZE distance test would always prevent coalescing the two together. No libhugetlbfs testsuite regressions (ppc64, POWER5). Signed-off-by: David Gibson <dwg@au1.ibm.com> Cc: William Lee Irwin III <wli@holomorphy.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'arch/i386')
0 files changed, 0 insertions, 0 deletions