Re: kernel panic

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Another page fault kernel panic, but it doesn't look the same as issue530.
:
:The sources are from July 11:
:
:DragonFly ylem.theshell.com 1.9.0-DEVELOPMENT DragonFly 1.9.0-DEVELOPMENT #26: Wed Jul 11 20:21:15 EDT 2007     root@ylem.theshell.com:/usr/obj/usr/src/sys/YLEM  i386
:
:Fatal trap 12: page fault while in kernel mode
:mp_lock = 00000000; cpuid = 0; lapic.id = 00000000
:fault virtual address   = 0x8000008b

    It's dying trying to traverse the in_ifaddrhead list in netinet/in.c.  

(kgdb) frame 7
#7  0xc0207a9b in in_localaddr (in={s_addr = 997540561})
    at /usr/src/sys/netinet/in.c:97
97                              if ((i & ia->ia_subnetmask) == ia->ia_subnet)
(kgdb) 

    ia is 0x7fffffff.  When I look at entry there's a lot of 0xdeadc0de
    data in there, which means the structure got freed without being removed
    from the list.

(kgdb) print in_ifaddrhead.tqh_first->ia_link.tqe_next->ia_link.tqe_next->ia_link.tqe_next
$12 = (struct in_ifaddr *) 0xe82ed840
(kgdb) print *$12
(kgdb) print *$12
$13 = {
  ia_ifa = {
    ifa_addr = 0xe82ed920, 
    ifa_dstaddr = 0xdeadc0de, 
    ifa_netmask = 0xdeadc0de, 
    if_data = {
      ifi_type = 222 'Þ', 
      ifi_physical = 192 'À', 
      ifi_addrlen = 173 '­', 
. ..
  ia_link = {
    tqe_next = 0x7fffffff, 
    tqe_prev = 0xffffffff
  }


    So we need to audit all the code that manipulates the in_ifaddrhead 
    list and check for structures that might get freed without being removed
    from the list.

						-Matt