On Tue, Jan 23, 2018 at 10:24 AM, Andrey Ryabinin <aryabinin@xxxxxxxxxxxxx> wrote: > > > On 01/19/2018 08:58 PM, Andrey Konovalov wrote: >> With KASAN enabled the kernel has two different memset() functions, one >> with KASAN checks (memset) and one without (__memset). KASAN uses some >> macro tricks to use the proper version where required. For example memset() >> calls in mm/slub.c are without KASAN checks, since they operate on poisoned >> slab object metadata. >> >> The issue is that clang emits memset() calls even when there is no memset() >> in the source code. They get linked with improper memset() implementation >> and the kernel fails to boot due to a huge amount of KASAN reports during >> early boot stages. >> > > So how did you observe this? Why am I not seeing this problem? I only observed this when I tried to cross-compile the kernel for arm64 with clang. I suspect this can happen on x86 as well. > >> The solution is to add -fno-builtin flag for files with KASAN_SANITIZE := n >> marker. >> > > I'm not sure I understand how is this solves the problem. And what clang does > instead of memset()? Does it inlines memset()? But according to GCC's man (clang's man is very vague about this) > -fno-builtin should do exactly the opposite - prevent inlining builtin functions > and always generate a function call. The issue is that the compiler is allowed to replace plain assignment with memset() calls. And -fno-builtin suppresses that behavior, but there are no mentions of this in the documentation that I could find. I also failed to find the exact place in the source code that leads to this, perhaps Nick can help with that. -- 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
