Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1671371 > unrolled thread

Re: [PATCH 4.4 30/30] mm: larger stack guard gap, between vmas

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 4.4 30/30] mm: larger stack guard gap, between vmas Hugh Dickins <hughd@google.com> - 2017-06-21 07:50 +0200
    Re: [PATCH 4.4 30/30] mm: larger stack guard gap, between vmas Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-06-24 17:10 +0200

#1671371 — Re: [PATCH 4.4 30/30] mm: larger stack guard gap, between vmas

On Mon, 19 Jun 2017, Greg Kroah-Hartman wrote:

> 4.4-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Hugh Dickins <hughd@google.com>
> 
> commit 1be7107fbe18eed3e319a6c3e83c78254b693acb upstream.

The 4.11 and 4.9 patches are fine, but I noticed a couple of corrections
to this 4.4 one.  There are very unlikely circumstances (on VM_GROWSUP
architectures only) in which that "highest_vm_end = end" line would be
wrong: several different ways to fix it, I'm tending to go with Andrea's
observation that the only need for update has already been done above,
so just VM_WARN_ON if it's unexpected.

Hugh

diff -purN 404n/include/linux/mm.h 404h/include/linux/mm.h
--- 404n/include/linux/mm.h	2017-06-20 16:48:17.162770068 -0700
+++ 404h/include/linux/mm.h	2017-06-20 17:36:35.871975695 -0700
@@ -1283,6 +1283,8 @@ static inline bool vma_is_anonymous(stru
 	return !vma->vm_ops;
 }
 
+int vma_is_stack_for_task(struct vm_area_struct *vma, struct task_struct *t);
+
 extern unsigned long move_page_tables(struct vm_area_struct *vma,
 		unsigned long old_addr, struct vm_area_struct *new_vma,
 		unsigned long new_addr, unsigned long len,
diff -purN 404n/mm/mmap.c 404h/mm/mmap.c
--- 404n/mm/mmap.c	2017-06-20 16:48:17.166770032 -0700
+++ 404h/mm/mmap.c	2017-06-20 17:42:31.312682716 -0700
@@ -923,7 +923,7 @@ again:			remove_next = 1 + (end > next->
 		else if (next)
 			vma_gap_update(next);
 		else
-			mm->highest_vm_end = end;
+			VM_WARN_ON(mm->highest_vm_end != vm_end_gap(vma));
 	}
 	if (insert && file)
 		uprobe_mmap(insert);

[toc] | [next] | [standalone]

#1674091

On Tue, Jun 20, 2017 at 10:41:01PM -0700, Hugh Dickins wrote:
> On Mon, 19 Jun 2017, Greg Kroah-Hartman wrote:
> 
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > From: Hugh Dickins <hughd@google.com>
> > 
> > commit 1be7107fbe18eed3e319a6c3e83c78254b693acb upstream.
> 
> The 4.11 and 4.9 patches are fine, but I noticed a couple of corrections
> to this 4.4 one.  There are very unlikely circumstances (on VM_GROWSUP
> architectures only) in which that "highest_vm_end = end" line would be
> wrong: several different ways to fix it, I'm tending to go with Andrea's
> observation that the only need for update has already been done above,
> so just VM_WARN_ON if it's unexpected.
> 
> Hugh
> 
> diff -purN 404n/include/linux/mm.h 404h/include/linux/mm.h
> --- 404n/include/linux/mm.h	2017-06-20 16:48:17.162770068 -0700
> +++ 404h/include/linux/mm.h	2017-06-20 17:36:35.871975695 -0700
> @@ -1283,6 +1283,8 @@ static inline bool vma_is_anonymous(stru
>  	return !vma->vm_ops;
>  }
>  
> +int vma_is_stack_for_task(struct vm_area_struct *vma, struct task_struct *t);
> +
>  extern unsigned long move_page_tables(struct vm_area_struct *vma,
>  		unsigned long old_addr, struct vm_area_struct *new_vma,
>  		unsigned long new_addr, unsigned long len,
> diff -purN 404n/mm/mmap.c 404h/mm/mmap.c
> --- 404n/mm/mmap.c	2017-06-20 16:48:17.166770032 -0700
> +++ 404h/mm/mmap.c	2017-06-20 17:42:31.312682716 -0700
> @@ -923,7 +923,7 @@ again:			remove_next = 1 + (end > next->
>  		else if (next)
>  			vma_gap_update(next);
>  		else
> -			mm->highest_vm_end = end;
> +			VM_WARN_ON(mm->highest_vm_end != vm_end_gap(vma));
>  	}
>  	if (insert && file)
>  		uprobe_mmap(insert);

Thank you, the first chunk was already in my updated tree, and I have
now added the second chunk and will run it through the 0-day tests to
see how it goes...

greg k-h

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web