Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1034046AbcJTPrB (ORCPT ); Thu, 20 Oct 2016 11:47:01 -0400 Received: from mx5-phx2.redhat.com ([209.132.183.37]:56615 "EHLO mx5-phx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755703AbcJTPrA (ORCPT ); Thu, 20 Oct 2016 11:47:00 -0400 Date: Thu, 20 Oct 2016 11:44:11 -0400 (EDT) From: Jan Stancek To: Mike Kravetz 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 Message-ID: <1012857651.1231744.1476978251733.JavaMail.zimbra@redhat.com> In-Reply-To: <1476933077-23091-1-git-send-email-mike.kravetz@oracle.com> References: <1476933077-23091-1-git-send-email-mike.kravetz@oracle.com> Subject: Re: [PATCH 0/1] mm/hugetlb: fix huge page reservation leak in private mapping error paths MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.34.26.57] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF49 (Win)/8.0.6_GA_5922) Thread-Topic: mm/hugetlb: fix huge page reservation leak in private mapping error paths Thread-Index: v0NGK+9PmKSGX26WsRfCqv+5Setnlg== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2597 Lines: 61 ----- 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. 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 > >