Re: hugetlb: preserve hugetlb pte dirty state

["Nish Aravamudan" <nish.aravamudan@gmail.com>]

On 2/6/07, Ken Chen <kenchen@google.com> wrote:
> __unmap_hugepage_range() is buggy that it does not preserve dirty
> state of huge_pte when unmapping hugepage range.  It causes data
> corruption in the event of dop_caches being used by sys admin.
> For example, an application creates a hugetlb file, modify pages,
> then unmap it.  While leaving the hugetlb file alive, comes along
> sys admin doing a "echo 3 > /proc/sys/vm/drop_caches".
> drop_pagecache_sb() will happily frees all pages that isn't marked
> dirty if there are no active mapping. Later when application remaps
> the hugetlb file back and all data are gone, triggering catastrophic
> flip over on application.
>
> Not only that, the internal resv_huge_pages count will also get all
> messed up.  Fix it up by marking page dirty appropriately.
>
> Signed-off-by: Ken Chen <kenchen@google.com>

This fixes my bug with HugePages_Rsvd going to 2^64 - 1.
("Hugepages_Rsvd goes huge in 2.6.20-rc7" is the subject on linux-mm).
Stable material, too, I would say.

Acked-by: Nishanth Aravamudan <nacc@us.ibm.com>

Thanks,
Nish

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>