Re: [PATCH] Kconfig.debug: disable CONFIG_FRAME_WARN for KASAN_STACK && CC_IS_CLANG by default

[Arnd Bergmann]

On Fri, Apr 21, 2023, at 17:10, Tudor Ambarus wrote:
> On 4/21/23 15:30, Arnd Bergmann wrote:
>> On Fri, Apr 21, 2023, at 15:01, Tudor Ambarus wrote:
>> 
>>> The conclusion is that when KASAN is enabled the stack usage increases a
>>> bit, but nothing unmanageable ~30-70 bytes, whereas when enabling
>>> KASAN_STACK the stack usage is excessive, from ~1.7K to ~5.8K for these
>>> cases.
>>>
>>> Disable CONFIG_FRAME_WARN for KASAN_STACK && CC_IS_CLANG by default.
>>> Adventurers can still override the default value by input prompt or
>>> explicit values in defconfigs in case they feel that some real warnings
>>> are missed.
>>>
>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@xxxxxxxxxx>
>> 
>> I think we are still better off with the warning enabled. When someone
>> really wants to run a kernel with KASAN_STACK enabled, they should have
>> a chance to see what they are getting into and not report any runtime
>> bugs that come from stack overflow. 
>> 
>
> Are such stack overflows warnings reliable when we know that stack
> instrumentation causes excessive stack usage? Until clang is fixed one
> shall hunt frame-larger-than warnings with KASAN_STACK disabled.

The main problem with stack frame usage is that the compiler cannot know
during compile time what the other functions are going to use, so it's
always a bit of guesswork, and we just try to make the limit as small
as possible without causing too much work addressing the warnings.

Only if the frame usage grows beyond the actual available stack size,
it's guaranteed to crash (I've seen 80KB for a single function, clearly
larger than 16kb of total stack size), but the larger it gets, the
more problems you'll run into.

We already discussed years ago how clang can improve a lot of the
cases here by reworking the amount of padding between variables
similar to how gcc does it. This won't work for all files, but for
a lot of them, and once clang gets fixed, we can address the
remaining ones by working around them in the kernel.

     Arnd