[PATCH 3/3] hugetlb: fix absurd HugePages_Rsvd

Hugh Dickins
2006-10-25T02:38:24Z

If you truncated an mmap'ed hugetlbfs file, then faulted on the truncated
area, /proc/meminfo's HugePages_Rsvd wrapped hugely "negative". Reinstate
my preliminary i_size check before attempting to allocate the page (though
this only fixes the most obvious case: more work will be needed here).

Signed-off-by: Hugh Dickins <hugh@veritas.com>
___

This is not a complete solution (what if hugetlb_no_page is actually
racing with truncate_hugepages?), and there are several other accounting
anomalies in here (private versus shared pages, hugetlbfs quota handling);
but those all need more thought. It'll probably make sense to use i_mutex
instead of hugetlb_instantiation_mutex, so locking out truncation and mmap.

mm/hugetlb.c | 3 +++
1 file changed, 3 insertions(+)

--- 2.6.19-rc3/mm/hugetlb.c 2006-10-24 04:34:37.000000000 +0100
+++ linux/mm/hugetlb.c 2006-10-24 16:23:17.000000000 +0100
@@ -478,6 +478,9 @@ int hugetlb_no_page(struct mm_struct *mm
retry:
page = find_lock_page(mapping, idx);
if (!page) {
+ size = i_size_read(mapping->host) >> HPAGE_SHIFT;
+ if (idx >= size)
+ goto out;
if (hugetlb_get_quota(mapping))
goto out;
page = alloc_huge_page(vma, address);