[PATCH 2/2] um: allocate a guard page to helper threads

[Johannes Berg]

On Sat, 2020-12-05 at 22:09 +0000, Anton Ivanov wrote:

> > -unsigned long alloc_stack(int order, int atomic)
> > +unsigned long alloc_stack(int atomic)
> >   {
> > -	unsigned long page;
> > +	unsigned long addr;
> >   	gfp_t flags = GFP_KERNEL;
> >   
> >   	if (atomic)
> >   		flags = GFP_ATOMIC;
> > -	page = __get_free_pages(flags, order);
> > +	addr = __get_free_pages(flags, 1);
> 
> Why are you dropping order?

It was always called with 0 as the order argument, so I didn't think it
was relevant. I guess we can keep it and allocate order+1, and then
reserve a page, but if then e.g. you wanted order 2 (16k) you'd actually
get 28k of usable stack and use up 32k. So I thought it was less
surprising if we'd remove it.

> I believe we do not fit in a stack of order 
> less than 2 on newer 64 bit and we need even more with valgrind.

Not sure what you mean by this, tbh. Running the whole of UML in
valgrind? Why would that require more stack? Kernel threads are
unaffected, and the helper threads don't do much that would really make
a significant difference between 32 and 64 bit?

johannes