Bug 212118

Summary: [vimage]: Fatal trap 12 | rename epair with vlan
Product: Base System Reporter: Ruslan <R100500B>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Some People CC: a.skurihin, bz, emaste, kp
Priority: --- Keywords: vimage
Version: 11.0-RC1   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
core.txt none

Description Ruslan 2016-08-24 17:42:34 UTC
Created attachment 174020 [details]
core.txt

Bind vlan from jail with vnet to epair, when second pair from host system was renamed cause Fatal trap 12. Bug occurs randomly (sometimes first try, sometimes 20 or more). To reproduce see script below.

<code>
#!/usr/local/bin/bash

create_destroy_jail() {
    echo " * Create epair"
    ifconfig epair create
    echo "* Rename 1 epair"
    ifconfig epair0a name repara
    ifconfig bridge0 addm repara
    ifconfig repara up

    echo " * Create jail"
    jail -i -c name=test vnet persist
    echo " * Bind epair"
    ifconfig epair0b vnet test

    echo " * jail: create valn"
    jexec test ifconfig vlan create
    echo " * jail: configure valn"
    jexec test ifconfig vlan0 192.168.200.2/24 vlandev epair0b vlan 10   <--- This step cause fatal trap

    echo " * Destroy jail"
    jail -r test
    echo " * Destroy epair"
    ifconfig repara destroy
}

for i in {1..50}; do
    echo " [$i]"
    create_destroy_jail
    echo " [$i]"
done
</code>

Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 03
fault virtual address   = 0x10
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff8284ae4d
stack pointer           = 0x28:0xfffffe023710b620
frame pointer           = 0x28:0xfffffe023710b680
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 12 (irq269: igb0:que 3)

(kgdb) bt
#0  doadump (textdump=1) at pcpu.h:221
#1  0xffffffff80afaabf in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:366
#2  0xffffffff80afb08b in vpanic (fmt=<value optimized out>, ap=<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:759
#3  0xffffffff80afaec3 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:690
#4  0xffffffff8039f857 in db_panic (addr=<value optimized out>, have_addr=false, count=0, modif=0x0) at /usr/src/sys/ddb/db_command.c:473
#5  0xffffffff8039eda9 in db_command (cmd_table=<value optimized out>) at /usr/src/sys/ddb/db_command.c:440
#6  0xffffffff8039eb04 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493
#7  0xffffffff803a1b0b in db_trap (type=<value optimized out>, code=<value optimized out>) at /usr/src/sys/ddb/db_main.c:251
#8  0xffffffff80b477e3 in kdb_trap (type=<value optimized out>, code=<value optimized out>, tf=<value optimized out>) at /usr/src/sys/kern/subr_kdb.c:654
#9  0xffffffff80ff0430 in trap_fatal (frame=0xfffffe023710b570, eva=16) at /usr/src/sys/amd64/amd64/trap.c:836
#10 0xffffffff80ff0663 in trap_pfault (frame=0xfffffe023710b570, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:691
#11 0xffffffff80fefc0d in trap (frame=0xfffffe023710b570) at /usr/src/sys/amd64/amd64/trap.c:442
#12 0xffffffff80fd2db1 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236
#13 0xffffffff8284ae4d in epair_transmit (ifp=0xfffff800127ec800, m=0xfffff8007c4a5000) at /usr/src/sys/modules/if_epair/../../net/if_epair.c:499
#14 0xffffffff8282362a in bridge_enqueue (sc=0xfffff800129f5c00, dst_ifp=<value optimized out>, m=<value optimized out>)
    at /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:1919
#15 0xffffffff82823939 in bridge_broadcast (sc=<value optimized out>, src_if=<value optimized out>, m=<value optimized out>, runfilt=1)
    at /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:2573
#16 0xffffffff82825fdf in bridge_forward (sc=0xfffff800129f5c00, sbif=0xfffff80012a30e00, m=0xffffffff8284b301) at /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:2233
#17 0xffffffff82824ffd in bridge_input (ifp=<value optimized out>, m=<value optimized out>) at /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:2353
#18 0xffffffff80c10367 in ether_nh_input (m=<value optimized out>) at /usr/src/sys/net/if_ethersubr.c:604
#19 0xffffffff80c27c8f in netisr_dispatch_src (proto=5, source=<value optimized out>, m=0xbae400) at /usr/src/sys/net/netisr.c:1121
#20 0xffffffff80c0f914 in ether_input (ifp=<value optimized out>, m=0x0) at /usr/src/sys/net/if_ethersubr.c:759
#21 0xffffffff82599da8 in igb_rxeof (count=366148096) at /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:4957
#22 0xffffffff825991f8 in igb_msix_que (arg=0xfffff800054d8938) at /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:1612
#23 0xffffffff80ab35ff in intr_event_execute_handlers (p=<value optimized out>, ie=<value optimized out>) at /usr/src/sys/kern/kern_intr.c:1262
#24 0xffffffff80ab3c16 in ithread_loop (arg=<value optimized out>) at /usr/src/sys/kern/kern_intr.c:1275
#25 0xffffffff80ab0105 in fork_exit (callout=0xffffffff80ab3b50 <ithread_loop>, arg=0xfffff800070b35a0, frame=0xfffffe023710bac0) at /usr/src/sys/kern/kern_fork.c:1038
#26 0xffffffff80fd32ee in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:611
#27 0x0000000000000000 in ?? ()

(kgdb) list *0xffffffff8284ae4d
0xffffffff8284ae4d is in epair_transmit (bpf.h:1487).
1482            struct bpf_if_ext *ext;
1483
1484            ext = (struct bpf_if_ext *)bpf;
1485            if (!LIST_EMPTY(&ext->bif_dlist))
1486                    return (1);
1487            return (0);
1488    }
1489
1490    #define BPF_TAP(_ifp,_pkt,_pktlen) do {                         \
1491            if (bpf_peers_present((_ifp)->if_bpf))                  \
Comment 1 Alexandr Skurikhin 2016-08-24 18:16:50 UTC
I have the same exact problem.
Comment 2 Kristof Provost freebsd_committer freebsd_triage 2017-09-24 14:03:31 UTC
I can not reproduce this on a current HEAD. Can you confirm that this is the case on your system too?
Comment 3 Kristof Provost freebsd_committer freebsd_triage 2017-11-01 10:03:27 UTC
This may have been the same issue as PR 213896 (fixed in r322590).

As there's no more user information I'm closing this.