https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- 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.