From owner-freebsd-net@FreeBSD.ORG Sun Jun 3 22:22:52 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E7FA1065696; Sun, 3 Jun 2012 22:22:52 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C779A8FC08; Sun, 3 Jun 2012 22:22:50 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA02923; Mon, 04 Jun 2012 01:22:48 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SbJCC-000Mzm-5e; Mon, 04 Jun 2012 01:22:48 +0300 Message-ID: <4FCBE3B6.1020003@FreeBSD.org> Date: Mon, 04 Jun 2012 01:22:46 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: FreeBSD-Current , freebsd-net@FreeBSD.org, melifaro@FreeBSD.org References: <4FCBCF7E.9020603@FreeBSD.org> In-Reply-To: <4FCBCF7E.9020603@FreeBSD.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: Subject: Re: null pointer panic in bpf_peers_present X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 22:22:52 -0000 on 03/06/2012 23:56 Andriy Gapon said the following: > > I wonder if anybody else is seeing this and if there is a fix... > This is very recent (today's) FreeBSD head with pretty dull network > configuration. During boot I run into the following panic: > > <118>Setting hostname: xxxxx > <118>Starting dhclient. > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x10 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff805a12a8 > stack pointer = 0x28:0xffffff8249905a10 > frame pointer = 0x28:0xffffff8249905a50 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12 (irq20: rl0) > trap number = 12 > panic: page fault > cpuid = 0 > curthread: 0xfffffe00115e14b0 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff802cc50a = db_trace_self_wrapper+0x2a > kdb_backtrace() at 0xffffffff8051ce2a = kdb_backtrace+0x3a > panic() at 0xffffffff804e9e36 = panic+0x266 > trap_fatal() at 0xffffffff80692f9d = trap_fatal+0x3ad > trap_pfault() at 0xffffffff806930d5 = trap_pfault+0x115 > trap() at 0xffffffff8069383b = trap+0x49b > calltrap() at 0xffffffff8067ec63 = calltrap+0x8 > --- trap 0xc, rip = 0xffffffff805a12a8, rsp = 0xffffff8249905a10, rbp = > 0xffffff8249905a50 --- > ether_nh_input() at 0xffffffff805a12a8 = ether_nh_input+0x118 > netisr_dispatch_src() at 0xffffffff805a9a31 = netisr_dispatch_src+0xb1 > netisr_dispatch() at 0xffffffff805a9c41 = netisr_dispatch+0x11 > ether_input() at 0xffffffff805a0c0e = ether_input+0xe > rl_rxeof() at 0xffffffff805f97c8 = rl_rxeof+0x228 > rl_intr() at 0xffffffff805faaa6 = rl_intr+0xf6 > intr_event_execute_handlers() at 0xffffffff804c17e9 = > intr_event_execute_handlers+0xd9 > ithread_loop() at 0xffffffff804c247f = ithread_loop+0x9f > fork_exit() at 0xffffffff804bef25 = fork_exit+0x125 > fork_trampoline() at 0xffffffff8067f18e = fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff8249905cf0, rbp = 0 --- > Uptime: 31s My current guess is that the panic occurs because of the newly added (r235745) bpf_ifdetach which is an ifnet_departure_event handler. My rc.conf is configured to do interface renaming and SIOCSIFNAME seems to post ifnet_departure_event followed by ifnet_arrival_event. Not sure if it's a window between ifnet_departure_event and ifnet_arrival_event when if_bpf is NULL, or if if_bpf is never restored in this case. > ether_nh_input+0x118 corresponds to: > (kgdb) list *ether_nh_input+0x118 > 0xffffffff805a12a8 is in ether_nh_input (bpf.h:1248). > 1243 > 1244 static __inline int > 1245 bpf_peers_present(struct bpf_if *bpf) > 1246 { > 1247 > 1248 if (!LIST_EMPTY(&bpf->bif_dlist)) > 1249 return (1); > 1250 return (0); > 1251 } > 1252 > > bpf argument seems to be NULL. > > Because of inlining the backtrace does not show a call to ether_input_internal > where ETHER_BPF_MTAP() invokes bpf_peers_present(). > The system has two network interfaces: rl and re. > -- Andriy Gapon