Created attachment 167749 [details] clang 3.8.0 aesni.ko crash summary I get a panic when loading aesni after clang/llvm 3.8.0 import. Steps to reproduce: 1) boot 2) kldload aesni 3) ...panic... I'm building with CPUTYPE?=haswell. A crash summary is attached.
I don't immediately have an idea why this happens just for the aesni.ko module. I had about 8 other modules loaded successfully on an amd64-freebsd11 instance, but loading aesni made it panic immediately. It turns out to be something in the kernel ELF linker, it panics in link_elf_reloc_local(), because findbase() apparently returned zero, since it couldn't find a certain entry: #10 0xffffffff80a32233 in panic (fmt=0xffffffff81afe320 "\004") at /share/dim/src/freebsd/base/projects/clang380-import/sys/kern/kern_shutdown.c:688 #11 0xffffffff80f9434b in link_elf_reloc_local (lf=<value optimized out>) at /share/dim/src/freebsd/base/projects/clang380-import/sys/kern/link_elf_obj.c:1396 #12 0xffffffff80f92aa3 in link_elf_load_file (cls=<value optimized out>, filename=<value optimized out>, result=<value optimized out>) at /share/dim/src/freebsd/base/projects/clang380-import/sys/kern/link_elf_obj.c:872 #13 0xffffffff80a06112 in linker_load_module (kldname=<value optimized out>, modname=0xfffff8005f242000 "aesni", parent=<value optimized out>, verinfo=<value optimized out>, lfpp=<value optimized out>) at linker_if.h:161 #14 0xffffffff80a07967 in kern_kldload (td=<value optimized out>, file=<value optimized out>, fileid=0xfffffe000024a984) at /share/dim/src/freebsd/base/projects/clang380-import/sys/kern/kern_linker.c:1037 #15 0xffffffff80a07a2b in sys_kldload (td=0xfffff8005f47c4d0, uap=<value optimized out>) at /share/dim/src/freebsd/base/projects/clang380-import/sys/kern/kern_linker.c:1063 (kgdb) frame 11 #11 0xffffffff80f9434b in link_elf_reloc_local (lf=<value optimized out>) at /share/dim/src/freebsd/base/projects/clang380-import/sys/kern/link_elf_obj.c:1396 1396 panic("lost base for relatab");
Created attachment 167751 [details] /usr/obj/usr/src/sys/modules/aesni directory built with clang 3.7.1 Attaching a module directory of the aesni module, built using clang 3.7.1.
Created attachment 167752 [details] /usr/obj/usr/src/sys/modules/aesni directory built with clang 3.8.0 Attaching a module directory of the aesni module, built using clang 3.8.0.
A commit references this bug: Author: kib Date: Sun Mar 6 00:31:11 UTC 2016 New revision: 296419 URL: https://svnweb.freebsd.org/changeset/base/296419 Log: In the link_elf_obj.c, handle sections of type SHT_AMD64_UNWIND same as SHT_PROGBITS. This is needed after the clang 3.8 import, which generates that type for .eh_frame section, which had SHT_PROGBITS type before. Reported by: Nikolai Lifanov <lifanov@mail.lifanov.com> PR: 207729 Tested by: dim (previous version) Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Changes: head/sys/kern/link_elf_obj.c
Nikolai, can you please also verify loading of the module, after Kostik's fix in r296419?
I just updated past r296419 and verified that the fix is effective. I can load aesni.ko without the crash now. Thank you.
This is now fixed by r296419 for the kernel loader, and r296428 for the boot loader.
A commit references this bug: Author: dim Date: Mon Mar 7 07:54:48 UTC 2016 New revision: 296438 URL: https://svnweb.freebsd.org/changeset/base/296438 Log: MFC r296419 (by kib): In the link_elf_obj.c, handle sections of type SHT_AMD64_UNWIND same as SHT_PROGBITS. This is needed after the clang 3.8 import, which generates that type for .eh_frame section, which had SHT_PROGBITS type before. Reported by: Nikolai Lifanov <lifanov@mail.lifanov.com> PR: 207729 Tested by: dim (previous version) Sponsored by: The FreeBSD Foundation MFC r296428: Since kernel modules can now contain sections of type SHT_AMD64_UNWIND, the boot loader should not skip over these anymore while loading images. Otherwise the kernel can still panic when it doesn't find the .eh_frame section belonging to the .rela.eh_frame section. Unfortunately this will require installing boot loaders from sys/boot before attempting to boot with a new kernel. Reviewed by: kib Changes: _U stable/10/ stable/10/sys/boot/common/load_elf_obj.c stable/10/sys/kern/link_elf_obj.c
A commit references this bug: Author: dim Date: Mon Mar 7 07:57:57 UTC 2016 New revision: 296439 URL: https://svnweb.freebsd.org/changeset/base/296439 Log: MFC r296419 (by kib): In the link_elf_obj.c, handle sections of type SHT_AMD64_UNWIND same as SHT_PROGBITS. This is needed after the clang 3.8 import, which generates that type for .eh_frame section, which had SHT_PROGBITS type before. Reported by: Nikolai Lifanov <lifanov@mail.lifanov.com> PR: 207729 Tested by: dim (previous version) Sponsored by: The FreeBSD Foundation MFC r296428: Since kernel modules can now contain sections of type SHT_AMD64_UNWIND, the boot loader should not skip over these anymore while loading images. Otherwise the kernel can still panic when it doesn't find the .eh_frame section belonging to the .rela.eh_frame section. Unfortunately this will require installing boot loaders from sys/boot before attempting to boot with a new kernel. Reviewed by: kib Changes: _U stable/9/ _U stable/9/sys/ _U stable/9/sys/boot/ stable/9/sys/boot/common/load_elf_obj.c stable/9/sys/kern/link_elf_obj.c
A commit references this bug: Author: dim Date: Mon Mar 7 19:59:08 UTC 2016 New revision: 296469 URL: https://svnweb.freebsd.org/changeset/base/296469 Log: MFC r296419 (by kib): In the link_elf_obj.c, handle sections of type SHT_AMD64_UNWIND same as SHT_PROGBITS. This is needed after the clang 3.8 import, which generates that type for .eh_frame section, which had SHT_PROGBITS type before. Reported by: Nikolai Lifanov <lifanov@mail.lifanov.com> PR: 207729 Tested by: dim (previous version) Sponsored by: The FreeBSD Foundation MFC r296428: Since kernel modules can now contain sections of type SHT_AMD64_UNWIND, the boot loader should not skip over these anymore while loading images. Otherwise the kernel can still panic when it doesn't find the .eh_frame section belonging to the .rela.eh_frame section. Unfortunately this will require installing boot loaders from sys/boot before attempting to boot with a new kernel. Reviewed by: kib Approved by: re (marius) Changes: _U releng/10.3/ releng/10.3/sys/boot/common/load_elf_obj.c releng/10.3/sys/kern/link_elf_obj.c
(In reply to commit-hook from comment #10) > A commit references this bug: > > Author: dim > Date: Mon Mar 7 19:59:08 UTC 2016 > New revision: 296469 > URL: https://svnweb.freebsd.org/changeset/base/296469 > > Log: > MFC r296428: > > Unfortunately this will require installing boot loaders from sys/boot > before attempting to boot with a new kernel. > Is this restricted to 9, and 10? Or is this across the board? If this is affects all "supported" versions. It seems to scream POLA. Or is this just temporary? Just wondering. Thanks --Chris
(In reply to Chris Hutchinson from comment #11) > Is this restricted to 9, and 10? Or is this across the board? > If this is affects all "supported" versions. It seems to scream POLA. > Or is this just temporary? This is only of consequence if you are upgrading from 9.x or 10.x directly to the most recent 11-CURRENT. (Normally, this isn't advised, of course.) This is why the changes have gone into stable/9 and stable/10 now, to make future upgrades smoother. Since the necessary changes have now also landed in time for 10.3-RELEASE, that also makes it easier to upgrade from there to 11-CURRENT.
(In reply to Dimitry Andric from comment #12) After r296467, loader change is not critical, but desirable to have. If you use old loader, some of your preloaded modules would not load, but kernel does not panic. After the kernel booted, you can kldunload and then kldload the failed modules.
(In reply to Konstantin Belousov from comment #13) > (In reply to Dimitry Andric from comment #12) > After r296467, loader change is not critical, but desirable to have. If you > use old loader, some of your preloaded modules would not load, but kernel > does not panic. After the kernel booted, you can kldunload and then kldload > the failed modules. Thank you *very* much for the reply, Dimitry, Konstantin. So if I'm on anything (including 11) *prior* to the landing of r296467. A loader update *is* required. At least if one wants to expect *normal* behavior. At least that's how I interpret this. Thanks again! --Chris