Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754743AbcJTDMr (ORCPT ); Wed, 19 Oct 2016 23:12:47 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:19440 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752444AbcJTDMq (ORCPT ); Wed, 19 Oct 2016 23:12:46 -0400 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 Subject: [PATCH 0/1] mm/hugetlb: fix huge page reservation leak in private mapping error paths Date: Wed, 19 Oct 2016 20:11:16 -0700 Message-Id: <1476933077-23091-1-git-send-email-mike.kravetz@oracle.com> X-Mailer: git-send-email 2.7.4 X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1628 Lines: 34 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 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