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

[Anton Ivanov]

On 06/12/2020 08:11, Johannes Berg wrote:
> 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?

According to the description of the stack order option in the config it 
does.

> Kernel threads are
> unaffected, and the helper threads don't do much that would really make
> a significant difference between 32 and 64 bit?

OK, I need to have a look again on where do we use the order parameter 
and what that config option really means.

> johannes
>
>

-- 
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/