Re: [PATCH 0/1] mm/hugetlb: fix huge page reservation leak in private mapping error paths
From: Mike Kravetz
Date: Thu Oct 20 2016 - 12:31:01 EST
On 10/20/2016 08:44 AM, Jan Stancek wrote:
> ----- Original Message -----
>> From: "Mike Kravetz" <mike.kravetz@xxxxxxxxxx>
>> To: linux-mm@xxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
>> Cc: "Aneesh Kumar K . V" <aneesh.kumar@xxxxxxxxxxxxxxxxxx>, "Naoya Horiguchi" <n-horiguchi@xxxxxxxxxxxxx>, "Michal
>> Hocko" <mhocko@xxxxxxxx>, "Kirill A . Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>, "Hillf Danton"
>> <hillf.zj@xxxxxxxxxxxxxxx>, "Dave Hansen" <dave.hansen@xxxxxxxxxxxxxxx>, "Jan Stancek" <jstancek@xxxxxxxxxx>, "Mike
>> Kravetz" <mike.kravetz@xxxxxxxxxx>
>> Sent: Thursday, 20 October, 2016 5:11:16 AM
>> Subject: [PATCH 0/1] mm/hugetlb: fix huge page reservation leak in private mapping error paths
>> This issue was discovered by Jan Stancek as described in
>> Error paths in hugetlb_cow() and hugetlb_no_page() do not properly clean
>> up reservation entries when freeing a newly allocated huge page. This
>> issue was introduced with commit 67961f9db8c4 ("mm/hugetlb: fix huge page
>> reserve accounting for private mappings). That commit uses the information
>> in private mapping reserve maps to determine if a reservation was already
>> consumed. This is important in the case of hole punch and truncate as the
>> pages are released, but reservation entries are not restored.
>> This patch restores the reserve entries in hugetlb_cow and hugetlb_no_page
>> such that reserve entries are consistent with the global reservation count.
>> The huge page reservation code is quite hard to follow, and this patch
>> makes it even more complex. One thought I had was to change the way
>> hole punch and truncate work so that private mapping pages are not thrown
>> away. This would eliminate the need for this patch as well as 67961f9db8c4.
>> It would change the existing semantics (as seen by the user) in this area,
>> but I believe the documentation (man pages) say the behavior is unspecified.
>> This could be a future change as well as rewriting the existing reservation
>> code to make it easier to understand/maintain. Thoughts?
>> In any case, this patch addresses the immediate issue.
> Just to confirm, I ran this patch on my setup (without the patch from Aneesh)
> with libhugetlbfs testsuite in loop for several hours. There were no
> ENOMEM/OOM failures, I did not observe resv leak after it finished.
Thanks for the testing Jan.
I do not have access to a Power system, so I simulated the condition to
>> Mike Kravetz (1):
>> mm/hugetlb: fix huge page reservation leak in private mapping error
>> mm/hugetlb.c | 66
>> 1 file changed, 66 insertions(+)