On Mon, Jun 13, 2016 at 4:51 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: > On Mon, Jun 13, 2016 at 2:11 PM, Andrew Morton > <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: >> On Tue, 14 Jun 2016 03:37:57 +0800 kbuild test robot <fengguang.wu@xxxxxxxxx> wrote: >> >>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/mel/linux mm-vmscan-node-lru-v7r3 >>> head: 276a5614a25ce20248f42bd4fb025b80ae0c9be1 >>> commit: 44c61fe5d7f13025a2a1f6efbbc0da75ad93ee19 [38/200] mm: SLUB freelist randomization >>> config: x86_64-randconfig-x018-06140033 (attached as .config) >>> compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430 >>> reproduce: >>> git checkout 44c61fe5d7f13025a2a1f6efbbc0da75ad93ee19 >>> # save the attached .config to linux build tree >>> make ARCH=x86_64 >>> >>> All errors (new ones prefixed by >>): >>> >>> mm/built-in.o: In function `init_cache_random_seq': >>> >> slub.c:(.text+0x507dc): undefined reference to `cache_random_seq_create' >>> mm/built-in.o: In function `__kmem_cache_release': >>> >> (.text+0x53979): undefined reference to `cache_random_seq_destroy' > > With that config, I get these errors. The above errors were already fixed in mm-slub-freelist-randomization-fix (moving it out of CONFIG_SLABINFO). > >> I don't even get that far with that .config. With gcc-4.4.4 I get >> >> init/built-in.o: In function `initcall_blacklisted': >> main.c:(.text+0x41): undefined reference to `__stack_chk_guard' >> main.c:(.text+0xbe): undefined reference to `__stack_chk_guard' >> init/built-in.o: In function `do_one_initcall': >> (.text+0xeb): undefined reference to `__stack_chk_guard' >> init/built-in.o: In function `do_one_initcall': >> (.text+0x22b): undefined reference to `__stack_chk_guard' >> init/built-in.o: In function `name_to_dev_t': >> (.text+0x320): undefined reference to `__stack_chk_guard' >> init/built-in.o:(.text+0x52e): more undefined references to `__stack_chk_guard' > > This, I don't. I'm scratching my head about how that's possible. The > __stack_chk_guard is a compiler alias on x86... > >> Kees touched it last :) > > I'll take a closer look tomorrow... Stupid question: were you doing a build for x86? This error really shouldn't be possible since gcc defaults to tls for the guard on x86. I don't have gcc 4.4.4 easily available, but I don't think it even has the -mstack-protector-guard option to force this to change. (And I see no reference to this option in the kernel tree.) AFAICT this error should only happen when building with either -mstack-protector-guard=global or an architecture that forces that, along with some new code that triggers the stack protector but lacks the symbol at link time, which also seems impossible. :P -Kees -- Kees Cook Chrome OS & Brillo Security -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>