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

[Ben Hutchings]

On Wed, 2017-07-05 at 19:05 +0200, Michal Hocko wrote:
> 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?

It's not ideal, but why would someone set the stack limit that high
unless it's for an application that will actually use most of that
stack space?  Do you think that "increase the stack limit" has been
cargo-culted?

> Say you are 32b and you have an application
> with multiple stacks each doing its MAP_GROWSDOWN.
[...]

So this application is using dietlibc or uclibc?  glibc uses fixed-size 
mappings for new threads.

I suppose there's a risk that by doing this we would mamke
MAP_GROWSDOWN useful enough that it is more likely to be used for new
thread stacks in future.

Ben.

-- 
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.

Attachment: signature.asc
Description: This is a digitally signed message part