From owner-freebsd-net Mon Sep 4 22:42:39 2000 Delivered-To: freebsd-net@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (rina.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id 64E7E37B422; Mon, 4 Sep 2000 22:42:32 -0700 (PDT) Received: from rina.r.dl.itc.u-tokyo.ac.jp (tanimura@localhost [127.0.0.1]) by rina.r.dl.itc.u-tokyo.ac.jp (8.9.3+3.2W/3.7W-rina.r-0.1-11.01.2000) with ESMTP/IPv4 id OAA52773; Tue, 5 Sep 2000 14:42:11 +0900 (JST) Date: Tue, 05 Sep 2000 14:42:10 +0900 Message-ID: <14772.34738.630468.85559N@rina> From: Seigo Tanimura To: current@freebsd.org, net@freebsd.org Subject: the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr Cc: Seigo Tanimura User-Agent: Wanderlust/1.0.3 (Notorious) SEMI/1.13.4 (Terai) FLIM/1.12.7 (=?ISO-8859-4?Q?Y=FEzaki?=) MULE XEmacs/21.1 (patch 9) (Canyonlands) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have been suffering from this problem for almost 2 months. When I remove a pcmcia ethernet card from my laptop PC, routed(8) announces updated routing information by multicast, leading to a kernel panic. The stack trace looks like this: IdlePTD 4136960 initial pcb at 352840 panicstr: page fault panic messages: --- Syntax error: Unterminated quoted string --- #0 boot (howto=256) at ../../kern/kern_shutdown.c:310 310 dumppcb.pcb_cr3 = rcr3(); (kgdb) bt #0 boot (howto=256) at ../../kern/kern_shutdown.c:310 #1 0xc018f3e1 in panic (fmt=0xc02faf4f "page fault") at ../../kern/kern_shutdown.c:560 #2 0xc02b5043 in trap_fatal (frame=0xcb9b0d7c, eva=213493) at ../../i386/i386/trap.c:951 #3 0xc02b4ce5 in trap_pfault (frame=0xcb9b0d7c, usermode=0, eva=213493) at ../../i386/i386/trap.c:844 #4 0xc02b4877 in trap (frame={tf_fs = 16, tf_es = -969998320, tf_ds = 16, tf_edi = -1058687232, tf_esi = -1058687744, tf_ebp = -879030772, tf_isp = -879030872, tf_ebx = -1058661888, tf_edx = -1067786268, tf_ecx = 213485, tf_eax = -1058661888, tf_trapno = 12, tf_err = 0, tf_eip = -1071746146, tf_cs = 8, tf_eflags = 66054, tf_esp = -1067786496, tf_ss = -879030720}) at ../../i386/i386/trap.c:443 #5 0xc01e739e in ip_output (m0=0xc05adf00, opt=0x0, ro=0xcb424dc8, flags=32, imo=0xc0e5b700) at ../../netinet/ip_output.c:326 #6 0xc01e8e26 in rip_output (m=0xc05adf00, so=0xcae549c0, dst=33554656) at ../../netinet/raw_ip.c:234 #7 0xc01e9627 in rip_send (so=0xcae549c0, flags=0, m=0xc05adf00, nam=0xc0da7950, control=0x0, p=0xc62f9f60) at ../../netinet/raw_ip.c:566 #8 0xc01b281f in sosend (so=0xcae549c0, addr=0xc0da7950, uio=0xcb9b0ed4, top=0xc05adf00, control=0x0, flags=0, p=0xc62f9f60) at ../../kern/uipc_socket.c:614 #9 0xc01b63be in sendit (p=0xc62f9f60, s=5, mp=0xcb9b0f14, flags=0) at ../../kern/uipc_syscalls.c:519 #10 0xc01b7998 in sendto (p=0xc62f9f60, uap=0xcb9b0f80) at ../../kern/uipc_syscalls.c:571 #11 0xc02b51ba in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 134727225, tf_ebp = -1077937408, tf_isp = -879030316, tf_ebx = 134844928, tf_edx = 2, tf_ecx = -1, tf_eax = 133, tf_trapno = 7, tf_err = 2, tf_eip = 134573992, tf_cs = 31, tf_eflags = 659, tf_esp = -1077937484, tf_ss = 47}) at ../../i386/i386/trap.c:1150 #12 0xc02a8875 in Xint0x80_syscall () #13 0x8051b10 in ?? () #14 0x8050ff4 in ?? () #15 0x804c212 in ?? () #16 0x804813f in ?? () In ip_output(), imo->imo_multicast_ifp points to the removed interface, which is passed to IN_LOOKUP_MULTI() to cause a panic. This problem also occurs when we attempt to delete a multicast address from a removed interface. if_delmulti() derefers an ifp to the removed interface, ending up with a panic. The problem does not occur for unicast. http://people.FreeBSD.org/~tanimura/patches/mcastif.diff.gz is a workround patch. The idea is to track all of the active ifps, confirm an ifp to be active prior to dereferencing it, and free orphaned ifmultiaddrs attached to a removed ifp. It would be much more elegant if we could clean up the multicast information related to a removed interface, though. -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message