summaryrefslogtreecommitdiff
path: root/fs/dcache.c
diff options
context:
space:
mode:
authorHugh Dickins <hugh@veritas.com>2006-10-28 10:38:43 -0700
committerLinus Torvalds <torvalds@g5.osdl.org>2006-10-28 11:30:53 -0700
commit856fc29505556cf263f3dcda2533cf3766c14ab6 (patch)
tree986b301f967487043cac92c7381e6e92bbcfe146 /fs/dcache.c
parentb9d7e6ae82da124dc9c579fe1061264ef2a69407 (diff)
downloadlinux-3.10-856fc29505556cf263f3dcda2533cf3766c14ab6.tar.gz
linux-3.10-856fc29505556cf263f3dcda2533cf3766c14ab6.tar.bz2
linux-3.10-856fc29505556cf263f3dcda2533cf3766c14ab6.zip
[PATCH] hugetlb: fix prio_tree unit
hugetlb_vmtruncate_list was misconverted to prio_tree: its prio_tree is in units of PAGE_SIZE (PAGE_CACHE_SIZE) like any other, not HPAGE_SIZE (whereas its radix_tree is kept in units of HPAGE_SIZE, otherwise slots would be absurdly sparse). At first I thought the error benign, just calling __unmap_hugepage_range on more vmas than necessary; but on 32-bit machines, when the prio_tree is searched correctly, it happens to ensure the v_offset calculation won't overflow. As it stood, when truncating at or beyond 4GB, it was liable to discard pages COWed from lower offsets; or even to clear pmd entries of preceding vmas, triggering exit_mmap's BUG_ON(nr_ptes). Signed-off-by: Hugh Dickins <hugh@veritas.com> Cc: Adam Litke <agl@us.ibm.com> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: "Chen, Kenneth W" <kenneth.w.chen@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'fs/dcache.c')
0 files changed, 0 insertions, 0 deletions