All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luck, Tony" <tony.luck@intel.com>
To: linux-kernel@vger.kernel.org
Cc: linux-ia64@vger.kernel.org, linux-parisc@vger.kernel.org,
	Kyle McMartin <kyle@mcmartin.ca>, Helge Deller <deller@gmx.de>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	Matthew Wilcox <willy@linux.intel.com>
Subject: [RFC - PATCH] leave guard page for upwardly growing stacks too
Date: Fri, 20 Aug 2010 17:56:47 +0000	[thread overview]
Message-ID: <4c6ec1df290705bb68@agluck-desktop.sc.intel.com> (raw)

In commit 320b2b8de12698082609ebbc1a17165727f4c893
   mm: keep a guard page below a grow-down stack segment

we prevented stacks from growing downwards into other vma areas.
But some arhictectures (ia64 and pa-risc) have stacks that
grow upwards. Provide the same protection for them.

Signed-off-by: Tony Luc <tony.luck@intel.com>

---

Pointed out to me by Matthew Wilcox.

DANGER, DANGER - NOT TESTED on pa-risc yet DO NOT APPLY WITHOUT AN ACK FROM PA-RISC LAND!

Are there any other architectures with upward growing stacks?

diff --git a/mm/memory.c b/mm/memory.c
index b6e5fd2..9dcef72 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2760,21 +2760,35 @@ out_release:
 }
 
 /*
- * This is like a special single-page "expand_downwards()",
- * except we must first make sure that 'address-PAGE_SIZE'
+ * This is like a special single-page "expand_{down|up}wards()",
+ * except we must first make sure that 'address{-|+}PAGE_SIZE'
  * doesn't hit another vma.
  *
  * The "find_vma()" will do the right thing even if we wrap
  */
 static inline int check_stack_guard_page(struct vm_area_struct *vma, unsigned long address)
 {
-	address &= PAGE_MASK;
-	if ((vma->vm_flags & VM_GROWSDOWN) && address = vma->vm_start) {
-		address -= PAGE_SIZE;
-		if (find_vma(vma->vm_mm, address) != vma)
-			return -ENOMEM;
+	struct vm_area_struct *v;
+
+	if (vma->vm_flags & VM_GROWSDOWN) {
+		address &= PAGE_MASK;
+		if (address = vma->vm_start) {
+			address -= PAGE_SIZE;
+			if (find_vma(vma->vm_mm, address) != vma)
+				return -ENOMEM;
 
-		expand_stack(vma, address);
+			expand_stack(vma, address);
+		}
+	} else if (vma->vm_flags & VM_GROWSUP) {
+		address = PAGE_ALIGN(address + 1);
+		if (address = vma->vm_end) {
+			address += PAGE_SIZE;
+			if ((v = find_vma(vma->vm_mm, address)) &&
+				v->vm_start <= address) {
+				return -ENOMEM;
+			}
+			expand_upwards(vma, address);
+		}
 	}
 	return 0;
 }

WARNING: multiple messages have this Message-ID (diff)
From: "Luck, Tony" <tony.luck@intel.com>
To: linux-kernel@vger.kernel.org
Cc: linux-ia64@vger.kernel.org, linux-parisc@vger.kernel.org,
	"Kyle McMartin" <kyle@mcmartin.ca>,
	"Helge Deller" <deller@gmx.de>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	"Matthew Wilcox" <willy@linux.intel.com>
Subject: [RFC - PATCH] leave guard page for upwardly growing stacks too
Date: Fri, 20 Aug 2010 10:56:47 -0700	[thread overview]
Message-ID: <4c6ec1df290705bb68@agluck-desktop.sc.intel.com> (raw)

In commit 320b2b8de12698082609ebbc1a17165727f4c893
   mm: keep a guard page below a grow-down stack segment

we prevented stacks from growing downwards into other vma areas.
But some arhictectures (ia64 and pa-risc) have stacks that
grow upwards. Provide the same protection for them.

Signed-off-by: Tony Luc <tony.luck@intel.com>

---

Pointed out to me by Matthew Wilcox.

DANGER, DANGER - NOT TESTED on pa-risc yet DO NOT APPLY WITHOUT AN ACK FROM PA-RISC LAND!

Are there any other architectures with upward growing stacks?

diff --git a/mm/memory.c b/mm/memory.c
index b6e5fd2..9dcef72 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2760,21 +2760,35 @@ out_release:
 }
 
 /*
- * This is like a special single-page "expand_downwards()",
- * except we must first make sure that 'address-PAGE_SIZE'
+ * This is like a special single-page "expand_{down|up}wards()",
+ * except we must first make sure that 'address{-|+}PAGE_SIZE'
  * doesn't hit another vma.
  *
  * The "find_vma()" will do the right thing even if we wrap
  */
 static inline int check_stack_guard_page(struct vm_area_struct *vma, unsigned long address)
 {
-	address &= PAGE_MASK;
-	if ((vma->vm_flags & VM_GROWSDOWN) && address == vma->vm_start) {
-		address -= PAGE_SIZE;
-		if (find_vma(vma->vm_mm, address) != vma)
-			return -ENOMEM;
+	struct vm_area_struct *v;
+
+	if (vma->vm_flags & VM_GROWSDOWN) {
+		address &= PAGE_MASK;
+		if (address == vma->vm_start) {
+			address -= PAGE_SIZE;
+			if (find_vma(vma->vm_mm, address) != vma)
+				return -ENOMEM;
 
-		expand_stack(vma, address);
+			expand_stack(vma, address);
+		}
+	} else if (vma->vm_flags & VM_GROWSUP) {
+		address = PAGE_ALIGN(address + 1);
+		if (address == vma->vm_end) {
+			address += PAGE_SIZE;
+			if ((v = find_vma(vma->vm_mm, address)) &&
+				v->vm_start <= address) {
+				return -ENOMEM;
+			}
+			expand_upwards(vma, address);
+		}
 	}
 	return 0;
 }

             reply	other threads:[~2010-08-20 17:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-20 17:56 Luck, Tony [this message]
2010-08-20 17:56 ` [RFC - PATCH] leave guard page for upwardly growing stacks too Luck, Tony

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=4c6ec1df290705bb68@agluck-desktop.sc.intel.com \
    --to=tony.luck@intel.com \
    --cc=deller@gmx.de \
    --cc=jejb@parisc-linux.org \
    --cc=kyle@mcmartin.ca \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=willy@linux.intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.