lkml.org 
[lkml]   [2016]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/1] mm/hugetlb: fix huge page reservation leak in private mapping error paths




----- Original Message -----
> From: "Mike Kravetz" <mike.kravetz@oracle.com>
> To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
> Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>, "Naoya Horiguchi" <n-horiguchi@ah.jp.nec.com>, "Michal
> Hocko" <mhocko@suse.com>, "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>, "Hillf Danton"
> <hillf.zj@alibaba-inc.com>, "Dave Hansen" <dave.hansen@linux.intel.com>, "Jan Stancek" <jstancek@redhat.com>, "Mike
> Kravetz" <mike.kravetz@oracle.com>
> 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
> https://lkml.kernel.org/r/57FF7BB4.1070202@redhat.com
>
> 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.

Mike,

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.

Regards,
Jan

>
> Mike Kravetz (1):
> mm/hugetlb: fix huge page reservation leak in private mapping error
> paths
>
> mm/hugetlb.c | 66
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 66 insertions(+)
>
> --
> 2.7.4
>
>

\
 
 \ /
  Last update: 2016-10-20 17:47    [W:0.121 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site