Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1301405 > unrolled thread

Re: [PATCH] arm64: fix add kasan bug

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] arm64: fix add kasan bug Catalin Marinas <catalin.marinas@arm.com> - 2016-01-05 11:20 +0100
    Re: [PATCH] arm64: fix add kasan bug Andrey Ryabinin <ryabinin.a.a@gmail.com> - 2016-01-05 22:20 +0100
      Re: [PATCH] arm64: fix add kasan bug Catalin Marinas <catalin.marinas@arm.com> - 2016-01-08 19:30 +0100

#1301405 — Re: [PATCH] arm64: fix add kasan bug

On Thu, Dec 31, 2015 at 10:09:09AM +0000, zhongjiang wrote:
> From: zhong jiang <zhongjiang@huawei.com>
> 
> 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@huawei.com>
> ---
>  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?

With 4.5 we are going for separate IRQ stack on arm64, so the typical
stack overflow case no longer exists.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1302221

2016-01-05 13:10 GMT+03:00 Catalin Marinas <catalin.marinas@arm.com>:
> On Thu, Dec 31, 2015 at 10:09:09AM +0000, zhongjiang wrote:
>> From: zhong jiang <zhongjiang@huawei.com>
>>
>> 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@huawei.com>
>> ---
>>  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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1304859

On Wed, Jan 06, 2016 at 12:17:17AM +0300, Andrey Ryabinin wrote:
> 2016-01-05 13:10 GMT+03:00 Catalin Marinas <catalin.marinas@arm.com>:
> > On Thu, Dec 31, 2015 at 10:09:09AM +0000, zhongjiang wrote:
> >> From: zhong jiang <zhongjiang@huawei.com>
> >>
> >> 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@huawei.com>
> >> ---
> >>  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.

I think on arm64 we shouldn't be affected that badly. I did some tests
(well, running LTP and checking the maximum stack usage). Without KASan,
I get about 5-6KB usage maximum. Once KASan is enabled, the maximum
stack utilisation is around 8KB.

I also changed FRAME_WARN to be 2048 with KASAN but it didn't trigger
any warning on arm64 (defconfig + KASAN).

Of course, there is a risk of IRQ followed by softirq which is what led
us to increase the stack size to 16KB. However, in 4.5 we'll have
separate IRQ stacks while still keeping THREAD_SIZE to 16KB. In 4.6, the
plan is to try to reduce default THREAD_SIZE to 8KB.

So it's only in 4.6 (if we go for 8KB THREAD_SIZE) that we should
increase the stack when KASAN is enabled (though to 16KB rather than
32KB).

I don't think 4.5 needs any adjustments and for 4.4 I would only do this
*if* there is actually a regression. However, I haven't seen any such
report yet, in which case I NAK this patch (at least until further
information emerges).

--
Catalin
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web