From: Greg Kroah-Hartman Date: Fri, 13 Aug 2010 15:58:31 +0000 (-0700) Subject: mm patch for all branches X-Git-Tag: v2.6.32.19~3 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=4f353869f60cf17f046ced33bd13ea8198b93390;p=thirdparty%2Fkernel%2Fstable-queue.git mm patch for all branches --- diff --git a/review-2.6.27/mm-keep-a-guard-page-below-a-grow-down-stack-segment.patch b/review-2.6.27/mm-keep-a-guard-page-below-a-grow-down-stack-segment.patch new file mode 100644 index 00000000000..c3fd2aa197c --- /dev/null +++ b/review-2.6.27/mm-keep-a-guard-page-below-a-grow-down-stack-segment.patch @@ -0,0 +1,72 @@ +From 320b2b8de12698082609ebbc1a17165727f4c893 Mon Sep 17 00:00:00 2001 +From: Linus Torvalds +Date: Thu, 12 Aug 2010 17:54:33 -0700 +Subject: mm: keep a guard page below a grow-down stack segment + +From: Linus Torvalds + +commit 320b2b8de12698082609ebbc1a17165727f4c893 upstream. + +This is a rather minimally invasive patch to solve the problem of the +user stack growing into a memory mapped area below it. Whenever we fill +the first page of the stack segment, expand the segment down by one +page. + +Now, admittedly some odd application might _want_ the stack to grow down +into the preceding memory mapping, and so we may at some point need to +make this a process tunable (some people might also want to have more +than a single page of guarding), but let's try the minimal approach +first. + +Tested with trivial application that maps a single page just below the +stack, and then starts recursing. Without this, we will get a SIGSEGV +_after_ the stack has smashed the mapping. With this patch, we'll get a +nice SIGBUS just as the stack touches the page just above the mapping. + +Requested-by: Keith Packard +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/memory.c | 23 +++++++++++++++++++++++ + 1 file changed, 23 insertions(+) + +--- a/mm/memory.c ++++ b/mm/memory.c +@@ -2396,6 +2396,26 @@ out_nomap: + } + + /* ++ * This is like a special single-page "expand_downwards()", ++ * 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; ++ ++ expand_stack(vma, address); ++ } ++ return 0; ++} ++ ++/* + * We enter with non-exclusive mmap_sem (to exclude vma changes, + * but allow concurrent faults), and pte mapped but not yet locked. + * We return with mmap_sem still held, but pte unmapped and unlocked. +@@ -2408,6 +2428,9 @@ static int do_anonymous_page(struct mm_s + spinlock_t *ptl; + pte_t entry; + ++ if (check_stack_guard_page(vma, address) < 0) ++ return VM_FAULT_SIGBUS; ++ + /* Allocate our own private page. */ + pte_unmap(page_table); + diff --git a/review-2.6.27/series b/review-2.6.27/series index b343909af22..c1a60eade71 100644 --- a/review-2.6.27/series +++ b/review-2.6.27/series @@ -9,3 +9,4 @@ jfs-don-t-allow-os2-xattr-namespace-overlap-with-others.patch xen-drop-xen_sched_clock-in-favour-of-using-plain-wallclock-time.patch bdi-register-sysfs-bdi-device-only-once-per-queue.patch mm-backing-dev.c-remove-recently-added-warn_on.patch +mm-keep-a-guard-page-below-a-grow-down-stack-segment.patch diff --git a/review-2.6.32/mm-keep-a-guard-page-below-a-grow-down-stack-segment.patch b/review-2.6.32/mm-keep-a-guard-page-below-a-grow-down-stack-segment.patch new file mode 100644 index 00000000000..c7a57d44abb --- /dev/null +++ b/review-2.6.32/mm-keep-a-guard-page-below-a-grow-down-stack-segment.patch @@ -0,0 +1,72 @@ +From 320b2b8de12698082609ebbc1a17165727f4c893 Mon Sep 17 00:00:00 2001 +From: Linus Torvalds +Date: Thu, 12 Aug 2010 17:54:33 -0700 +Subject: mm: keep a guard page below a grow-down stack segment + +From: Linus Torvalds + +commit 320b2b8de12698082609ebbc1a17165727f4c893 upstream. + +This is a rather minimally invasive patch to solve the problem of the +user stack growing into a memory mapped area below it. Whenever we fill +the first page of the stack segment, expand the segment down by one +page. + +Now, admittedly some odd application might _want_ the stack to grow down +into the preceding memory mapping, and so we may at some point need to +make this a process tunable (some people might also want to have more +than a single page of guarding), but let's try the minimal approach +first. + +Tested with trivial application that maps a single page just below the +stack, and then starts recursing. Without this, we will get a SIGSEGV +_after_ the stack has smashed the mapping. With this patch, we'll get a +nice SIGBUS just as the stack touches the page just above the mapping. + +Requested-by: Keith Packard +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/memory.c | 23 +++++++++++++++++++++++ + 1 file changed, 23 insertions(+) + +--- a/mm/memory.c ++++ b/mm/memory.c +@@ -2630,6 +2630,26 @@ out_release: + } + + /* ++ * This is like a special single-page "expand_downwards()", ++ * 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; ++ ++ expand_stack(vma, address); ++ } ++ return 0; ++} ++ ++/* + * We enter with non-exclusive mmap_sem (to exclude vma changes, + * but allow concurrent faults), and pte mapped but not yet locked. + * We return with mmap_sem still held, but pte unmapped and unlocked. +@@ -2642,6 +2662,9 @@ static int do_anonymous_page(struct mm_s + spinlock_t *ptl; + pte_t entry; + ++ if (check_stack_guard_page(vma, address) < 0) ++ return VM_FAULT_SIGBUS; ++ + if (!(flags & FAULT_FLAG_WRITE)) { + entry = pte_mkspecial(pfn_pte(my_zero_pfn(address), + vma->vm_page_prot)); diff --git a/review-2.6.32/series b/review-2.6.32/series index c8a379a503d..5d613569ac5 100644 --- a/review-2.6.32/series +++ b/review-2.6.32/series @@ -109,3 +109,4 @@ ibmvfc-fix-command-completion-handling.patch ibmvfc-reduce-error-recovery-timeout.patch md-raid1-delay-reads-that-could-overtake-behind-writes.patch mm-fix-corruption-of-hibernation-caused-by-reusing-swap-during-image-saving.patch +mm-keep-a-guard-page-below-a-grow-down-stack-segment.patch diff --git a/review-2.6.34/mm-keep-a-guard-page-below-a-grow-down-stack-segment.patch b/review-2.6.34/mm-keep-a-guard-page-below-a-grow-down-stack-segment.patch new file mode 100644 index 00000000000..876aec5f59b --- /dev/null +++ b/review-2.6.34/mm-keep-a-guard-page-below-a-grow-down-stack-segment.patch @@ -0,0 +1,72 @@ +From 320b2b8de12698082609ebbc1a17165727f4c893 Mon Sep 17 00:00:00 2001 +From: Linus Torvalds +Date: Thu, 12 Aug 2010 17:54:33 -0700 +Subject: mm: keep a guard page below a grow-down stack segment + +From: Linus Torvalds + +commit 320b2b8de12698082609ebbc1a17165727f4c893 upstream. + +This is a rather minimally invasive patch to solve the problem of the +user stack growing into a memory mapped area below it. Whenever we fill +the first page of the stack segment, expand the segment down by one +page. + +Now, admittedly some odd application might _want_ the stack to grow down +into the preceding memory mapping, and so we may at some point need to +make this a process tunable (some people might also want to have more +than a single page of guarding), but let's try the minimal approach +first. + +Tested with trivial application that maps a single page just below the +stack, and then starts recursing. Without this, we will get a SIGSEGV +_after_ the stack has smashed the mapping. With this patch, we'll get a +nice SIGBUS just as the stack touches the page just above the mapping. + +Requested-by: Keith Packard +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/memory.c | 23 +++++++++++++++++++++++ + 1 file changed, 23 insertions(+) + +--- a/mm/memory.c ++++ b/mm/memory.c +@@ -2751,6 +2751,26 @@ out_release: + } + + /* ++ * This is like a special single-page "expand_downwards()", ++ * 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; ++ ++ expand_stack(vma, address); ++ } ++ return 0; ++} ++ ++/* + * We enter with non-exclusive mmap_sem (to exclude vma changes, + * but allow concurrent faults), and pte mapped but not yet locked. + * We return with mmap_sem still held, but pte unmapped and unlocked. +@@ -2763,6 +2783,9 @@ static int do_anonymous_page(struct mm_s + spinlock_t *ptl; + pte_t entry; + ++ if (check_stack_guard_page(vma, address) < 0) ++ return VM_FAULT_SIGBUS; ++ + if (!(flags & FAULT_FLAG_WRITE)) { + entry = pte_mkspecial(pfn_pte(my_zero_pfn(address), + vma->vm_page_prot)); diff --git a/review-2.6.34/series b/review-2.6.34/series index 0ec314e2203..f715fc082a5 100644 --- a/review-2.6.34/series +++ b/review-2.6.34/series @@ -52,3 +52,4 @@ i915-fix-ironlake-edp-panel-setup-v4.patch ibmvfc-fix-command-completion-handling.patch ibmvfc-reduce-error-recovery-timeout.patch md-raid1-delay-reads-that-could-overtake-behind-writes.patch +mm-keep-a-guard-page-below-a-grow-down-stack-segment.patch diff --git a/review-2.6.35/mm-keep-a-guard-page-below-a-grow-down-stack-segment.patch b/review-2.6.35/mm-keep-a-guard-page-below-a-grow-down-stack-segment.patch new file mode 100644 index 00000000000..b8c0bedf438 --- /dev/null +++ b/review-2.6.35/mm-keep-a-guard-page-below-a-grow-down-stack-segment.patch @@ -0,0 +1,72 @@ +From 320b2b8de12698082609ebbc1a17165727f4c893 Mon Sep 17 00:00:00 2001 +From: Linus Torvalds +Date: Thu, 12 Aug 2010 17:54:33 -0700 +Subject: mm: keep a guard page below a grow-down stack segment + +From: Linus Torvalds + +commit 320b2b8de12698082609ebbc1a17165727f4c893 upstream. + +This is a rather minimally invasive patch to solve the problem of the +user stack growing into a memory mapped area below it. Whenever we fill +the first page of the stack segment, expand the segment down by one +page. + +Now, admittedly some odd application might _want_ the stack to grow down +into the preceding memory mapping, and so we may at some point need to +make this a process tunable (some people might also want to have more +than a single page of guarding), but let's try the minimal approach +first. + +Tested with trivial application that maps a single page just below the +stack, and then starts recursing. Without this, we will get a SIGSEGV +_after_ the stack has smashed the mapping. With this patch, we'll get a +nice SIGBUS just as the stack touches the page just above the mapping. + +Requested-by: Keith Packard +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/memory.c | 23 +++++++++++++++++++++++ + 1 file changed, 23 insertions(+) + +--- a/mm/memory.c ++++ b/mm/memory.c +@@ -2760,6 +2760,26 @@ out_release: + } + + /* ++ * This is like a special single-page "expand_downwards()", ++ * 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; ++ ++ expand_stack(vma, address); ++ } ++ return 0; ++} ++ ++/* + * We enter with non-exclusive mmap_sem (to exclude vma changes, + * but allow concurrent faults), and pte mapped but not yet locked. + * We return with mmap_sem still held, but pte unmapped and unlocked. +@@ -2772,6 +2792,9 @@ static int do_anonymous_page(struct mm_s + spinlock_t *ptl; + pte_t entry; + ++ if (check_stack_guard_page(vma, address) < 0) ++ return VM_FAULT_SIGBUS; ++ + if (!(flags & FAULT_FLAG_WRITE)) { + entry = pte_mkspecial(pfn_pte(my_zero_pfn(address), + vma->vm_page_prot)); diff --git a/review-2.6.35/series b/review-2.6.35/series index 63c3110a7bc..93023718d0d 100644 --- a/review-2.6.35/series +++ b/review-2.6.35/series @@ -65,3 +65,4 @@ irq-add-new-irq-flag-irqf_no_suspend.patch xen-do-not-suspend-ipi-irqs.patch crypto-testmgr-add-an-option-to-disable-cryptoalgos-self-tests.patch ext4-fix-freeze-deadlock-under-io.patch +mm-keep-a-guard-page-below-a-grow-down-stack-segment.patch