This is a note to let you know that I've just added the patch titled
mm: propagate error from stack expansion even for guard page
to the 3.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mm-propagate-error-from-stack-expansion-even-for-guard-page.patch
and it can be found in the queue-3.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From fee7e49d45149fba60156f5b59014f764d3e3728 Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 6 Jan 2015 13:00:05 -0800
Subject: mm: propagate error from stack expansion even for guard page
From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
commit fee7e49d45149fba60156f5b59014f764d3e3728 upstream.
Jay Foad reports that the address sanitizer test (asan) sometimes gets
confused by a stack pointer that ends up being outside the stack vma
that is reported by /proc/maps.
This happens due to an interaction between RLIMIT_STACK and the guard
page: when we do the guard page check, we ignore the potential error
from the stack expansion, which effectively results in a missing guard
page, since the expected stack expansion won't have been done.
And since /proc/maps explicitly ignores the guard page (commit
d7824370e263: "mm: fix up some user-visible effects of the stack guard
page"), the stack pointer ends up being outside the reported stack area.
This is the minimal patch: it just propagates the error. It also
effectively makes the guard page part of the stack limit, which in turn
measn that the actual real stack is one page less than the stack limit.
Let's see if anybody notices. We could teach acct_stack_growth() to
allow an extra page for a grow-up/grow-down stack in the rlimit test,
but I don't want to add more complexity if it isn't needed.
Reported-and-tested-by: Jay Foad <jay.foad@xxxxxxxxx>
Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
include/linux/mm.h | 2 +-
mm/memory.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1630,7 +1630,7 @@ extern int expand_downwards(struct vm_ar
#if VM_GROWSUP
extern int expand_upwards(struct vm_area_struct *vma, unsigned long address);
#else
- #define expand_upwards(vma, address) do { } while (0)
+ #define expand_upwards(vma, address) (0)
#endif
/* Look up the first VMA which satisfies addr < vm_end, NULL if none. */
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3200,7 +3200,7 @@ static inline int check_stack_guard_page
if (prev && prev->vm_end == address)
return prev->vm_flags & VM_GROWSDOWN ? 0 : -ENOMEM;
- expand_downwards(vma, address - PAGE_SIZE);
+ return expand_downwards(vma, address - PAGE_SIZE);
}
if ((vma->vm_flags & VM_GROWSUP) && address + PAGE_SIZE == vma->vm_end) {
struct vm_area_struct *next = vma->vm_next;
@@ -3209,7 +3209,7 @@ static inline int check_stack_guard_page
if (next && next->vm_start == address + PAGE_SIZE)
return next->vm_flags & VM_GROWSUP ? 0 : -ENOMEM;
- expand_upwards(vma, address + PAGE_SIZE);
+ return expand_upwards(vma, address + PAGE_SIZE);
}
return 0;
}
Patches currently in stable-queue which might be from torvalds@xxxxxxxxxxxxxxxxxxxx are
queue-3.10/perf-x86-intel-uncore-make-sure-only-uncore-events-are-collected.patch
queue-3.10/nilfs2-fix-the-nilfs_iget-vs.-nilfs_new_inode-races.patch
queue-3.10/mm-vmscan-prevent-kswapd-livelock-due-to-pfmemalloc-throttled-process-being-killed.patch
queue-3.10/ocfs2-fix-journal-commit-deadlock.patch
queue-3.10/scripts-kernel-doc-don-t-eat-struct-members-with-__aligned.patch
queue-3.10/mm-don-t-count-the-stack-guard-page-towards-rlimit_stack.patch
queue-3.10/perf-fix-events-installation-during-moving-group.patch
queue-3.10/mm-propagate-error-from-stack-expansion-even-for-guard-page.patch
queue-3.10/perf-session-do-not-fail-on-processing-out-of-order-event.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html