(unknown charset) Re: null pointer panic in bpf_peers_present

From: (unknown charset) Andriy Gapon <avg_at_FreeBSD.org>
Date: Mon, 04 Jun 2012 01:22:46 +0300
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
Received on Sun Jun 03 2012 - 20:22:52 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:27 UTC