linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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>
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	[thread overview]
Message-ID: <1476933077-23091-1-git-send-email-mike.kravetz@oracle.com> (raw)

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

             reply	other threads:[~2016-10-20  3:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-20  3:11 Mike Kravetz [this message]
2016-10-20  3:11 ` [PATCH 1/1] mm/hugetlb: fix huge page reservation leak in private mapping error paths Mike Kravetz
2016-10-23 11:34   ` Aneesh Kumar K.V
2016-10-23 11:36   ` Aneesh Kumar K.V
2016-10-24 20:40     ` Mike Kravetz
2016-11-01 16:37   ` Mike Kravetz
2016-11-02  3:15     ` Hillf Danton
2016-10-20 15:44 ` [PATCH 0/1] " Jan Stancek
2016-10-20 16:29   ` Mike Kravetz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1476933077-23091-1-git-send-email-mike.kravetz@oracle.com \
    --to=mike.kravetz@oracle.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hillf.zj@alibaba-inc.com \
    --cc=jstancek@redhat.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=n-horiguchi@ah.jp.nec.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).