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

[Michal Hocko]

On Wed 05-07-17 17:58:45, Ben Hutchings wrote:
[...]
> diff --git a/mm/mmap.c b/mm/mmap.c
> index c7906ae1a7a1..f8131a94e56e 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2307,6 +2307,25 @@ int expand_upwards(struct vm_area_struct *vma, unsigned long address)
>  }
>  #endif /* CONFIG_STACK_GROWSUP || CONFIG_IA64 */
>  
> +unsigned long __vm_start_gap(struct vm_area_struct *vma)
> +{
> +	unsigned long stack_limit =
> +		current->signal->rlim[RLIMIT_STACK].rlim_cur;
> +	unsigned long vm_start;
> +
> +	if (stack_limit != RLIM_INFINITY &&
> +	    vma->vm_end - vma->vm_start < stack_limit)
> +		vm_start = vma->vm_end - PAGE_ALIGN(stack_limit);

This is exactly what I was worried about in my previous email. Say
somebody sets stack ulimit to 1G or so. Should we reduce the available
address space that much? Say you are 32b and you have an application
with multiple stacks each doing its MAP_GROWSDOWN. You are quickly out
of address space. That's why I've said that we would need to find a cap
for the user defined limit. How much that should be though? Few (tens,
hundreds) megs. If we can figure that up I would be of course quite
happy about such a change because MAP_GROWSDOWN doesn't work really well
these days.

> +	else
> +		vm_start = vma->vm_start;
> +
> +	vm_start -= stack_guard_gap;
> +	if (vm_start > vma->vm_start)
> +		vm_start = 0;
> +
> +	return vm_start;
> +}
> +
>  /*
>   * vma is the first one with address < vma->vm_start.  Have to extend vma.
>   */
> 
> -- 
> Ben Hutchings
> For every complex problem
> there is a solution that is simple, neat, and wrong.



-- 
Michal Hocko
SUSE Labs