[PATCH 3.2 103/152] mm: Don't count the stack guard page towards RLIMIT_STACK

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Linus Torvalds 

commit 690eac53daff34169a4d74fc7bfbd388c4896abb upstream.

Commit fee7e49d4514 ("mm: propagate error from stack expansion even for
guard page") made sure that we return the error properly for stack
growth conditions.  It also theorized that counting the guard page
towards the stack limit might break something, but also said "Let's see
if anybody notices".

Somebody did notice.  Apparently android-x86 sets the stack limit very
close to the limit indeed, and including the guard page in the rlimit
check causes the android 'zygote' process problems.

So this adds the (fairly trivial) code to make the stack rlimit check be
against the actual real stack size, rather than the size of the vma that
includes the guard page.

Reported-and-tested-by: Chih-Wei Huang 
Cc: Jay Foad 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings 
---
 mm/mmap.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1648,14 +1648,17 @@ static int acct_stack_growth(struct vm_a
 {
struct mm_struct *mm = vma->vm_mm;
struct rlimit *rlim = current->signal->rlim;
-   unsigned long new_start;
+   unsigned long new_start, actual_size;
 
/* address space limit tests */
if (!may_expand_vm(mm, grow))
return -ENOMEM;
 
/* Stack limit test */
-   if (size > ACCESS_ONCE(rlim[RLIMIT_STACK].rlim_cur))
+   actual_size = size;
+   if (size && (vma->vm_flags & (VM_GROWSUP | VM_GROWSDOWN)))
+   actual_size -= PAGE_SIZE;
+   if (actual_size > ACCESS_ONCE(rlim[RLIMIT_STACK].rlim_cur))
return -ENOMEM;
 
/* mlock limit tests */

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.2 103/152] mm: Don't count the stack guard page towards RLIMIT_STACK

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Linus Torvalds torva...@linux-foundation.org

commit 690eac53daff34169a4d74fc7bfbd388c4896abb upstream.

Commit fee7e49d4514 (mm: propagate error from stack expansion even for
guard page) made sure that we return the error properly for stack
growth conditions.  It also theorized that counting the guard page
towards the stack limit might break something, but also said Let's see
if anybody notices.

Somebody did notice.  Apparently android-x86 sets the stack limit very
close to the limit indeed, and including the guard page in the rlimit
check causes the android 'zygote' process problems.

So this adds the (fairly trivial) code to make the stack rlimit check be
against the actual real stack size, rather than the size of the vma that
includes the guard page.

Reported-and-tested-by: Chih-Wei Huang cwhu...@android-x86.org
Cc: Jay Foad jay.f...@gmail.com
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
 mm/mmap.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1648,14 +1648,17 @@ static int acct_stack_growth(struct vm_a
 {
struct mm_struct *mm = vma-vm_mm;
struct rlimit *rlim = current-signal-rlim;
-   unsigned long new_start;
+   unsigned long new_start, actual_size;
 
/* address space limit tests */
if (!may_expand_vm(mm, grow))
return -ENOMEM;
 
/* Stack limit test */
-   if (size  ACCESS_ONCE(rlim[RLIMIT_STACK].rlim_cur))
+   actual_size = size;
+   if (size  (vma-vm_flags  (VM_GROWSUP | VM_GROWSDOWN)))
+   actual_size -= PAGE_SIZE;
+   if (actual_size  ACCESS_ONCE(rlim[RLIMIT_STACK].rlim_cur))
return -ENOMEM;
 
/* mlock limit tests */

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/