netgraph calling VFS from network swi (was: Re: 5.2-RC fatal trap 12)

[Robert Watson]

On Fri, 12 Dec 2003, Robert Watson wrote:

> On Fri, 12 Dec 2003, Alexander Motin wrote:
> 
> > Same problem on other hardware but on system booted from same HDD: 
> 
> This is a really scary stack trace -- it looks like netgraph is calling
> into the kernel linker from the network swi, and that in turn is hitting
> VFS.  I may have missed earlier messages in this thread, but do you have a
> precise list of userland activities you're performing to trigger this?  It
> looks like you're doing something that causes netgraph to load additional
> modules...  Which would probably not be such a bad thing if it happened in
> a different thread context.

FYI, you can probably work around the panic by preloading whatever module
it's trying to load, such that the module is already available when the
trigger event happens and it doesn't try to load the module in that
context.

> 
> Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
> robert at fledge.watson.org      Senior Research Scientist, McAfee Research
> 
> 
> > 
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 0; apic id = 00
> > fault virtual address   = 0x0
> > fault code              = supervisor read, page not present
> > instruction pointer     = 0x8:0xc056cbd3
> > stack pointer           = 0x10:0xd2a3e79c
> > frame pointer           = 0x10:0xd2a3e7b8
> > code segment            = base 0x0, limit 0xfffff, type 0x1b
> >                          = DPL 0, pres 1, def32 1, gran 1
> > processor eflags        = interrupt enabled, resume, IOPL = 0
> > current process         = 29 (swi1: net)
> > trap number             = 12
> > panic: page fault
> > cpuid = 0;
> > 
> > (kgdb) bt
> > #0  0xc057601b in doadump ()
> > #1  0xc0576661 in boot ()
> > #2  0xc0576a3e in panic ()
> > #3  0xc06d32cc in trap_fatal ()
> > #4  0xc06d2f72 in trap_pfault ()
> > #5  0xc06d2b83 in trap ()
> > #6  0xc06bfd78 in calltrap ()
> > #7  0xc05d2c2c in vref ()
> > #8  0xc05cb7c8 in namei ()
> > #9  0xc05ddc11 in vn_open_cred ()
> > #10 0xc05dd9b3 in vn_open ()
> > #11 0xc0568dd4 in linker_hints_lookup ()
> > #12 0xc05692ea in linker_search_module ()
> > #13 0xc05694cb in linker_load_module ()
> > #14 0xc3de0a36 in ng_make_node () from /boot/kernel/netgraph.ko
> > #15 0xc3de2ab1 in ng_mkpeer () from /boot/kernel/netgraph.ko
> > #16 0xc3de4861 in ng_generic_msg () from /boot/kernel/netgraph.ko
> > #17 0xc3de44c5 in ng_apply_item () from /boot/kernel/netgraph.ko
> > #18 0xc3de6944 in ngintr () from /boot/kernel/netgraph.ko
> > #19 0xc05e99d9 in swi_net ()
> > #20 0xc05631f2 in ithread_loop ()
> > #21 0xc05621a4 in fork_exit ()
> > _______________________________________________
> > freebsd-current at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
> > 
> 
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>