linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andy Whitcroft <apw@shadowen.org>
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, agl@us.ibm.com, wli@holomorphy.com,
	kenchen@google.com, dwg@au1.ibm.com, andi@firstfloor.org,
	Mel Gorman <mel@csn.ul.ie>,
	dean@arctic.org, abh@cray.com, Andy Whitcroft <apw@shadowen.org>
Subject: [PATCH 1/3] record MAP_NORESERVE status on vmas and fix small page mprotect reservations
Date: Tue, 20 May 2008 17:55:36 +0100	[thread overview]
Message-ID: <1211302536.0@pinky> (raw)
In-Reply-To: exportbomb.1211302309@pinky

When a small page mapping is created with mmap() reservations are created
by default for any memory pages required.  When the region is read/write
the reservation is increased for every page, no reservation is needed for
read-only regions (as they implicitly share the zero page).  Reservations
are tracked via the VM_ACCOUNT vma flag which is present when the region
has reservation backing it.  When we convert a region from read-only to
read-write new reservations are aquired and VM_ACCOUNT is set.  However,
when a read-only map is created with MAP_NORESERVE it is indistinguishable
from a normal mapping.  When we then convert that to read/write we are
forced to incorrectly create reservations for it as we have no record of
the original MAP_NORESERVE.

This patch introduces a new vma flag VM_NORESERVE which records the
presence of the original MAP_NORESERVE flag.  This allows us to distinguish
these two circumstances and correctly account the reserve.

As well as fixing this FIXME in the code, this makes it much easier to
introduce MAP_NORESERVE support for huge pages as this flag is available
consistantly for the life of the mapping.  VM_ACCOUNT on the other hand
is heavily used at the generic level in association with small pages.

Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
 include/linux/mm.h |    1 +
 mm/mmap.c          |    3 +++
 mm/mprotect.c      |    6 ++----
 3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0ffed95..c2be4c3 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -100,6 +100,7 @@ extern unsigned int kobjsize(const void *objp);
 #define VM_DONTEXPAND	0x00040000	/* Cannot expand with mremap() */
 #define VM_RESERVED	0x00080000	/* Count as reserved_vm like IO */
 #define VM_ACCOUNT	0x00100000	/* Is a VM accounted object */
+#define VM_NORESERVE	0x00200000	/* should the VM suppress accounting */
 #define VM_HUGETLB	0x00400000	/* Huge TLB Page VM */
 #define VM_NONLINEAR	0x00800000	/* Is non-linear (remap_file_pages) */
 #define VM_MAPPED_COPY	0x01000000	/* T if mapped copy of data (nommu mmap) */
diff --git a/mm/mmap.c b/mm/mmap.c
index fac6633..98ab014 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1101,6 +1101,9 @@ munmap_back:
 	if (!may_expand_vm(mm, len >> PAGE_SHIFT))
 		return -ENOMEM;
 
+	if (flags & MAP_NORESERVE)
+		vm_flags |= VM_NORESERVE;
+
 	if (accountable && (!(flags & MAP_NORESERVE) ||
 			    sysctl_overcommit_memory == OVERCOMMIT_NEVER)) {
 		if (vm_flags & VM_SHARED) {
diff --git a/mm/mprotect.c b/mm/mprotect.c
index a5bf31c..e0d0a6d 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -155,12 +155,10 @@ mprotect_fixup(struct vm_area_struct *vma, struct vm_area_struct **pprev,
 	 * If we make a private mapping writable we increase our commit;
 	 * but (without finer accounting) cannot reduce our commit if we
 	 * make it unwritable again.
-	 *
-	 * FIXME? We haven't defined a VM_NORESERVE flag, so mprotecting
-	 * a MAP_NORESERVE private mapping to writable will now reserve.
 	 */
 	if (newflags & VM_WRITE) {
-		if (!(oldflags & (VM_ACCOUNT|VM_WRITE|VM_SHARED))) {
+		if (!(oldflags & (VM_ACCOUNT|VM_WRITE|
+						VM_SHARED|VM_NORESERVE))) {
 			charged = nrpages;
 			if (security_vm_enough_memory(charged))
 				return -ENOMEM;

--
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:[~2008-05-20 16:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-20 16:54 [PATCH 0/3] MAP_NORESERVE for hugetlb mappings V2 Andy Whitcroft
2008-05-20 16:55 ` Andy Whitcroft [this message]
2008-05-20 16:55 ` [PATCH 2/3] hugetlb-move-reservation-region-support-earlier Andy Whitcroft
2008-05-20 16:55 ` [PATCH 3/3] hugetlb-allow-huge-page-mappings-to-be-created-without-reservations Andy Whitcroft
  -- strict thread matches above, loose matches on Subject: below --
2008-05-27 23:09 [PATCH 0/3] MAP_NORESERVE for hugetlb mappings V3 Andy Whitcroft
2008-05-27 23:09 ` [PATCH 1/3] record MAP_NORESERVE status on vmas and fix small page mprotect reservations Andy Whitcroft
2008-05-07 20:24 [PATCH 0/3] MAP_NORESERVE for hugetlb mappings V1 Andy Whitcroft
2008-05-07 20:24 ` [PATCH 1/3] record MAP_NORESERVE status on vmas and fix small page mprotect reservations Andy Whitcroft

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=1211302536.0@pinky \
    --to=apw@shadowen.org \
    --cc=abh@cray.com \
    --cc=agl@us.ibm.com \
    --cc=andi@firstfloor.org \
    --cc=dean@arctic.org \
    --cc=dwg@au1.ibm.com \
    --cc=kenchen@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=wli@holomorphy.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).