Bug 15057

Summary: loading a kld module with a unresolved symbol crashes
Product: Base System Reporter: assar <assar>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me CC: assar
Priority: Normal    
Version: 3.3-RELEASE   
Hardware: Any   
OS: Any   

Description assar 1999-11-23 05:10:01 UTC
This bug was fixed for -current in kern_module.c:1.18.  The original
PR seems to have been lost, 1179 (the number mentioned in the CVS log)
is another unrelated PR and I've been unable to find the real PR.

This fix has been in current for some time and I think it can safely
be MFC-ed to stable.  And it's also quite annoying to have the kernel
crash just because it can't load a module.

Fix: 

kern_module.c:1.18
How-To-Repeat: 
kldload a module when a unresolved symbol.
Comment 1 peter 1999-11-28 11:52:40 UTC
assar@stacken.kth.se wrote:
> >Number:         15057
> >Category:       kern
> >Synopsis:       loading a kld module with a unresolved symbol crashes
> 
> This bug was fixed for -current in kern_module.c:1.18.  The original
> PR seems to have been lost, 1179 (the number mentioned in the CVS log)
> is another unrelated PR and I've been unable to find the real PR.
> 
> This fix has been in current for some time and I think it can safely
> be MFC-ed to stable.  And it's also quite annoying to have the kernel
> crash just because it can't load a module.

The 1.18 fix was for a different problem and I don't see how it's applicable
to this case.  newmod->file is set unconditionally when loaded.

Can you give me some more information please?  Such as a traceback showing
where the crash is?

Cheers,
-Peter
Comment 2 assar 1999-11-28 12:38:22 UTC
Peter Wemm <peter@netplex.com.au> writes:
> The 1.18 fix was for a different problem and I don't see how it's applicable
> to this case.  newmod->file is set unconditionally when loaded.

Hm, I did go by the CVS comments but other than that I would have to
agree.  The problem is however fixed in -current but I haven't not
been able to pinpoint what patch fixed it.

> Can you give me some more information please?  Such as a traceback showing
> where the crash is?

Sure, here's a cut-n-paste from kgdb.  Tell me if there's more
information you need.


/assar

IdlePTD 4190208
initial pcb at 36b12c
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xe51c
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc015df8c
stack pointer           = 0x10:0xc3f80e00
frame pointer           = 0x10:0xc3f80e0c
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 27873 (kldload)
interrupt mask          = 
trap number             = 12
panic: page fault

syncing disks... 55 55 51 41 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 giving up

dumping to dev 20001, offset 163840
dump 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 
---
#0  boot (howto=256) at ../../kern/kern_shutdown.c:285
285                     dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0  boot (howto=256) at ../../kern/kern_shutdown.c:285
#1  0xc016a511 in panic (fmt=0xc033703e "page fault")
    at ../../kern/kern_shutdown.c:446
#2  0xc02a1e66 in trap_fatal (frame=0xc3f80dc4, eva=58652)
    at ../../i386/i386/trap.c:942
#3  0xc02a1b1f in trap_pfault (frame=0xc3f80dc4, usermode=0, eva=58652)
    at ../../i386/i386/trap.c:835
#4  0xc02a177e in trap (frame={tf_es = -1007157232, tf_ds = 16, 
      tf_edi = -1058748548, tf_esi = -1058748544, tf_ebp = -1007153652, 
      tf_isp = -1007153684, tf_ebx = 58652, tf_edx = 58824, 
      tf_ecx = -1058748540, tf_eax = -1058748548, tf_trapno = 12, tf_err = 0, 
      tf_eip = -1072308340, tf_cs = 8, tf_eflags = 66050, tf_esp = 0, 
      tf_ss = -1060441472}) at ../../i386/i386/trap.c:437
#5  0xc015df8c in linker_file_sysuninit (lf=0xc0caf280)
    at ../../kern/kern_linker.c:204
#6  0xc015e3d6 in linker_file_unload (file=0xc0caf280)
    at ../../kern/kern_linker.c:413
#7  0xc016048a in link_elf_load_file (filename=0xc0cb2000 "./xfs.ko", 
    result=0xc3f80f3c) at ../../kern/link_elf.c:682
#8  0xc015fc8e in link_elf_load_module (filename=0xc0cb2000 "./xfs.ko", 
    result=0xc3f80f3c) at ../../kern/link_elf.c:340
#9  0xc015e0d6 in linker_load_file (filename=0xc0cb2000 "./xfs.ko", 
    result=0xc3f80f5c) at ../../kern/kern_linker.c:265
#10 0xc015e89a in kldload (p=0xc3f1f180, uap=0xc3f80f94)
    at ../../kern/kern_linker.c:655
#11 0xc02a20c3 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 1, 
      tf_esi = 1, tf_ebp = -1077945412, tf_isp = -1007153180, 
      tf_ebx = -1077945360, tf_edx = 2, tf_ecx = 118, tf_eax = 304, 
      tf_trapno = 12, tf_err = 2, tf_eip = 134513676, tf_cs = 31, 
      tf_eflags = 582, tf_esp = -1077945432, tf_ss = 39})
    at ../../i386/i386/trap.c:1100
#12 0xc02972fc in Xint0x80_syscall ()
#13 0x80480e9 in ?? ()
(kgdb) f 5
#5  0xc015df8c in linker_file_sysuninit (lf=0xc0caf280)
    at ../../kern/kern_linker.c:204
204                 if ((*sipp)->subsystem >= (*xipp)->subsystem ||
(kgdb) p sipp
$1 = (struct sysinit **) 0xc0e4c780
(kgdb) p xipp
$2 = (struct sysinit **) 0x0
Comment 3 assar 1999-11-28 12:54:27 UTC
I wrote:
> Hm, I did go by the CVS comments but other than that I would have to
> agree.  The problem is however fixed in -current but I haven't not
> been able to pinpoint what patch fixed it.

So I've figured out what changes actually fixes the problem and tried
them on 3.3.

You want:

sys/linker.h: 1.12
kern/kern_linker.c: 1.23
kern/link_elf.c: 1.12

/assar
Comment 4 Peter Wemm freebsd_committer freebsd_triage 1999-11-28 14:50:29 UTC
State Changed
From-To: open->closed

Suggested changes MFC'd, revs: 
1.21.2.3  +4 -1      src/sys/kern/kern_linker.c 
1.17.2.3  +4 -1      src/sys/kern/link_aout.c 
1.11.2.3  +5 -1      src/sys/kern/link_elf.c 
1.11.2.2  +3 -1      src/sys/sys/linker.h 
Thanks!