Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754871AbcJTQa4 (ORCPT ); Thu, 20 Oct 2016 12:30:56 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:29904 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754501AbcJTQay (ORCPT ); Thu, 20 Oct 2016 12:30:54 -0400 Subject: Re: [PATCH 0/1] mm/hugetlb: fix huge page reservation leak in private mapping error paths To: Jan Stancek References: <1476933077-23091-1-git-send-email-mike.kravetz@oracle.com> <1012857651.1231744.1476978251733.JavaMail.zimbra@redhat.com> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Aneesh Kumar K . V" , Naoya Horiguchi , Michal Hocko , "Kirill A . Shutemov" , Hillf Danton , Dave Hansen From: Mike Kravetz Message-ID: <15eb1a2f-25f3-7d4a-e792-0b71bef6a720@oracle.com> Date: Thu, 20 Oct 2016 09:29:35 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1012857651.1231744.1476978251733.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2833 Lines: 71 On 10/20/2016 08:44 AM, Jan Stancek wrote: > > > > > ----- Original Message ----- >> From: "Mike Kravetz" >> To: linux-mm@kvack.org, linux-kernel@vger.kernel.org >> Cc: "Aneesh Kumar K . V" , "Naoya Horiguchi" , "Michal >> Hocko" , "Kirill A . Shutemov" , "Hillf Danton" >> , "Dave Hansen" , "Jan Stancek" , "Mike >> Kravetz" >> 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. Thanks for the testing Jan. I do not have access to a Power system, so I simulated the condition to test. -- Mike Kravetz > > 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 >> >>