Bug 207729 - llvm 3.8.0 import (r296417) - panic in aesni.ko
Summary: llvm 3.8.0 import (r296417) - panic in aesni.ko
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-05 22:55 UTC by Nikolai Lifanov
Modified: 2016-03-07 22:33 UTC (History)
4 users (show)

See Also:


Attachments
clang 3.8.0 aesni.ko crash summary (115.38 KB, text/plain)
2016-03-05 22:55 UTC, Nikolai Lifanov
no flags Details
/usr/obj/usr/src/sys/modules/aesni directory built with clang 3.7.1 (23.14 KB, application/x-xz)
2016-03-05 23:22 UTC, Dimitry Andric
no flags Details
/usr/obj/usr/src/sys/modules/aesni directory built with clang 3.8.0 (23.27 KB, application/x-xz)
2016-03-05 23:23 UTC, Dimitry Andric
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nikolai Lifanov 2016-03-05 22:55:53 UTC
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.
Comment 1 Dimitry Andric freebsd_committer freebsd_triage 2016-03-05 23:14:43 UTC
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");
Comment 2 Dimitry Andric freebsd_committer freebsd_triage 2016-03-05 23:22:47 UTC
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.
Comment 3 Dimitry Andric freebsd_committer freebsd_triage 2016-03-05 23:23:28 UTC
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.
Comment 4 commit-hook freebsd_committer freebsd_triage 2016-03-06 00:32:10 UTC
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
Comment 5 Dimitry Andric freebsd_committer freebsd_triage 2016-03-06 00:58:45 UTC
Nikolai, can you please also verify loading of the module, after Kostik's fix in r296419?
Comment 6 Nikolai Lifanov 2016-03-06 04:47:27 UTC
I just updated past r296419 and verified that the fix is effective.
I can load aesni.ko without the crash now. Thank you.
Comment 7 Dimitry Andric freebsd_committer freebsd_triage 2016-03-06 17:37:45 UTC
This is now fixed by r296419 for the kernel loader, and r296428 for the boot loader.
Comment 8 commit-hook freebsd_committer freebsd_triage 2016-03-07 07:55:46 UTC
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
Comment 9 commit-hook freebsd_committer freebsd_triage 2016-03-07 07:58:48 UTC
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
Comment 10 commit-hook freebsd_committer freebsd_triage 2016-03-07 19:59:50 UTC
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
Comment 11 Chris Hutchinson 2016-03-07 21:29:12 UTC
(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
Comment 12 Dimitry Andric freebsd_committer freebsd_triage 2016-03-07 21:42:38 UTC
(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.
Comment 13 Konstantin Belousov freebsd_committer freebsd_triage 2016-03-07 21:45:57 UTC
(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.
Comment 14 Chris Hutchinson 2016-03-07 22:33:33 UTC
(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