--- Comment #22 from Arnd Bergmann <arnd at linaro dot org> ---
(In reply to Jakub Jelinek from comment #20)
> I haven't heard any answer to #c16 whether it actually helped the kernel or
> not.

Sorry about that. Yes, it definitely helped the kernel a lot. At this point, we
also have localized workarounds to the same effect (using local variables
instead of accessing inline function arguments) in all functions that exceeded
the arbitrary 2048 byte stack size limit, and backported into the 4.4 kernel
and later, but with the newer gcc releases, we also get a lower stack
consumption for lots of other functions that were high but below that limit.

I had hoped that we could also do this on gcc-7 branch without KASAN, as high
stack consumption is always problematic for the kernel, and the same functions
that got bumped over the warning limit with KASAN still suffer from wasted
stack space on older compilers without KASAN. Since you consider that too
invasive for the stable releases, my current workaround has to suffice.

One side issue that is not solved at all by the patch is
-fsanitize-address-use-after-scope, since that still leads to extreme stack
usage in the kernel. The problem here is that it forces many local variables
into separate stack slots even when they could get reused without
-fsanitize-address-use-after-scope, making it still actively dangerous to run
kernels built with this option.
My workaround in the kernel is now to have that option disabled by default and
only enabled when users explicitly turn it on. I still think it would be nice
to address that in the way I originally suggested, by copying the behavior that
LLVM uses with its variably sized redzone area.

Reply via email to