On Mon, Jun 26, 2017 at 3:58 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > * With asan-stack=1, gcc uses at least 64 bytes per such variable > (two times ASAN_RED_ZONE_SIZE), while clang only uses 16 bytes > (2 * (1<<kDefaultShadowScale)). With asan-stack=0, they do not > use any more space than with kasan completely disabled > (no -fsanitize=kernel-address). I asked around the Linaro toolchain team today, and arrived at this commit in llvm: https://github.com/llvm-mirror/llvm/commit/daa1bf3b74054 Prior to this, the llvm behavior was the same as gcc, using 64 bytes for each small (<= 16 byte) variable instead of just 16 or 32 as it does now. llvm now also uses a larger redzone (up to 256 bytes) for very large stack objects, which also seems like a good idea. While it would be hard to argue that the gcc behavior is a bug, it should be possible to implement the same optimization in gcc, and that would solve a lot of the stack size issues with KASAN. > Can you say which behavior you find 'sane' or 'not sane' here, > specifically? Maybe we can make future gcc releases use a > smaller redzone like clang does. > > If we find a way to improve gcc so it uses less stack here, we still > have a problem with existing compilers still producing dangerously > high stack usage, as well as annoying warnings for an allmodconfig > build as soon as we start warning about this again. This problem obviously still stands. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
