2016-01-05 13:10 GMT+03:00 Catalin Marinas <catalin.marinas@xxxxxxx>:
> On Thu, Dec 31, 2015 at 10:09:09AM +0000, zhongjiang wrote:
>> From: zhong jiang <zhongjiang@xxxxxxxxxx>
>>
>> In general, each process have 16kb stack space to use, but
>> stack need extra space to store red_zone when kasan enable.
>> the patch fix above question.
>>
>> Signed-off-by: zhong jiang <zhongjiang@xxxxxxxxxx>
>> ---
>> arch/arm64/include/asm/thread_info.h | 15 +++++++++++++--
>> 1 file changed, 13 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h
>> index 90c7ff2..45b5a7e 100644
>> --- a/arch/arm64/include/asm/thread_info.h
>> +++ b/arch/arm64/include/asm/thread_info.h
> [...]
>> +#ifdef CONFIG_KASAN
>> +#define THREAD_SIZE 32768
>> +#else
>> #define THREAD_SIZE 16384
>> +#endif
>
> I'm not really keen on increasing the stack size to 32KB when KASan is
> enabled (that's 8 4K pages). Have you actually seen a real problem with
> the default size?
> How large is the red_zone?
>
Typical stack frame layout looks like this:
| 32-byte redzone | variable-1| padding-redzone to the next
32-byte boundary| variable-2|padding |.... | 32-byte redzone|
AFAIK gcc creates redzones only if it can't prove that all accesses
to variable are valid (e.g. reference to variable passed to external
function).
Besides redzones, stack could be increased due to additional spilling.
Although arm64 should be less affected by this since it has more
registers than x86_64.
On x86_64 I've seen few bad cases where stack frame of a single
function was bloated up to 6K.
> With 4.5 we are going for separate IRQ stack on arm64, so the typical
> stack overflow case no longer exists.
>
> --
> Catalin
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>