Kernel panic when using deprecated prefix on stf(4)

Chris Cowart ccowart at bitgravity.com
Thu Apr 26 00:46:26 UTC 2012


Hello, 

I'm currently trying to configure an stf(4) interface to make 2002::/16
directly reachable from hosts with native IPv6.

The "output-only" example at the end of the EXAMPLES section of stf(4)
leads to consistent kernel panics for me. I've observed the panics on
8.1.

The example looks like this:

     # ifconfig ne0 inet 133.4.5.6 netmask 0xffffff00
     # ifconfig stf0 inet6 2002:8504:0506:0000:a00:5aff:fe38:6f86 \
             prefixlen 16 alias deprecated link0
     # route add -inet6 2002:: -prefixlen 16 ::1
     # route change -inet6 2002:: -prefixlen 16 ::1 -ifp stf0

I've narrowed the panics down to this:

# ifconfig stf0 create
# ifconfig stf0 inet6 2002:480d:5667::1/16 deprecated

The "link0" flag appears to just disable decapsulation (making it
impossible to ping6 2002:480d:5667::1). It has no effect on the crash.

I've tried various iterations of the route add/change commands in my
experimenting; I don't think they're necessary. The routing table looks
like this immediately following bringing stf0 up with a deprecated
prefix:

| $ route get -inet6 2002::/16
|    route to: 2002::
| destination: 2002::
|        mask: ffff::
|   interface: stf0
|       flags: <UP,DONE>
|  recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
|        0         0         0         0      1280         1         0 

And 2002::/16 hosts ping.

Generally within 2-3 minutes (often much sooner), I get a kernel panic.
I've been able to reproduce the issue on our custom 8.1 build on Xen and
bare metal as well as on a stock 8.1-RELEASE-p5 running in an ESX vm. I
don't think you'll have any trouble seeing the same results.

The backtraces have been all over the place. Here are a couple of
samples:

| Fatal trap 12: page fault while in kernel mode
| cpuid = 1; apic id = 02
| fault virtual address   = 0x420
| fault code              = supervisor write data, page not present
| instruction pointer     = 0x20:0xffffffff805013bc
| stack pointer           = 0x28:0xffffff80000438b0
| frame pointer           = 0x28:0xffffff80000438d0
| 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 (swi4: clock)
| trap number             = 12
| panic: page fault
| cpuid = 1
| KDB: stack backtrace:
| db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
| panic() at panic+0x182
| trap_fatal() at trap_fatal+0x2ad
| trap_pfault() at trap_pfault+0x22d
| trap() at trap+0x369
| calltrap() at calltrap+0x8
| --- trap 0xc, rip = 0xffffffff805013bc, rsp = 0xffffff80000438b0, rbp = 0xffffff80000438d0 ---
| _mtx_lock_flags() at _mtx_lock_flags+0x1c
| in6_purgeaddr() at in6_purgeaddr+0x59
| nd6_timer() at nd6_timer+0x8f
| softclock() at softclock+0x2a2
| intr_event_execute_handlers() at intr_event_execute_handlers+0x66
| ithread_loop() at ithread_loop+0x8e
| fork_exit() at fork_exit+0x112
| fork_trampoline() at fork_trampoline+0xe
| --- trap 0, rip = 0, rsp = 0xffffff8000043d30, rbp = 0 ---
| Uptime: 57s

| Fatal trap 12: page fault while in kernel mode
| cpuid = 1; apic id = 02
| fault virtual address   = 0x420
| fault code              = supervisor write data, page not present
| instruction pointer     = 0x20:0xffffffff805013bc
| stack pointer           = 0x28:0xffffff80000438b0
| frame pointer           = 0x28:0xffffff80000438d0
| 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 (swi4: clock)
| trap number             = 12
| panic: page fault
| cpuid = 1
| KDB: stack backtrace:
| db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
| panic() at panic+0x182
| trap_fatal() at trap_fatal+0x2ad
| trap_pfault() at trap_pfault+0x22d
| trap() at trap+0x369
| calltrap() at calltrap+0x8
| --- trap 0xc, rip = 0xffffffff805013bc, rsp = 0xffffff80000438b0, rbp = 0xffffff80000438d0 ---
| _mtx_lock_flags() at _mtx_lock_flags+0x1c
| in6_purgeaddr() at in6_purgeaddr+0x59
| nd6_timer() at nd6_timer+0x8f
| softclock() at softclock+0x2a2
| intr_event_execute_handlers() at intr_event_execute_handlers+0x66
| ithread_loop() at ithread_loop+0x8e
| fork_exit() at fork_exit+0x112
| fork_trampoline() at fork_trampoline+0xe
| --- trap 0, rip = 0, rsp = 0xffffff8000043d30, rbp = 0 ---
| Uptime: 5d4h44m38s

| Fatal trap 12: page fault while in kernel mode
| cpuid = 1; apic id = 02
| fault virtual address   = 0x3e0
| fault code              = supervisor write data, page not present
| instruction pointer     = 0x20:0xffffffff8050d37d
| stack pointer           = 0x28:0xffffff80001cc510
| frame pointer           = 0x28:0xffffff80001cc530
| 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         = 1410 (ping6)
| trap number             = 12
| panic: page fault
| cpuid = 1
| KDB: stack backtrace:
| db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
| panic() at panic+0x182
| trap_fatal() at trap_fatal+0x2ad
| trap_pfault() at trap_pfault+0x22d
| trap() at trap+0x369
| calltrap() at calltrap+0x8
| --- trap 0xc, rip = 0xffffffff8050d37d, rsp = 0xffffff80001cc510, rbp = 0xffffff80001cc530 ---
| _rw_wlock() at _rw_wlock+0x1d
| in6_setscope() at in6_setscope+0x40
| in6_selectsrc() at in6_selectsrc+0x36e
| rip6_output() at rip6_output+0x26a
| rip6_send() at rip6_send+0x11e
| sosend_generic() at sosend_generic+0x347
| kern_sendit() at kern_sendit+0x1a5
| sendit() at sendit+0xdc
| sendmsg() at sendmsg+0x87
| syscall() at syscall+0x12b
| Xfast_syscall() at Xfast_syscall+0xe1
| --- syscall (28, FreeBSD ELF64, sendmsg), rip = 0x800a5b64c, rsp = 0x7fffffffe5e8, rbp = 0x10 ---
| Uptime: 4m24s

Please let me know if there's any more information I can provide and/or
whether I should get this into a PR.

Thanks,

-- 
Chris Cowart
Lead Network Engineer
BitGravity, Inc.
A subsidiary of Tata Communications, Ltd.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20120426/1cd833e3/attachment.pgp


More information about the freebsd-net mailing list