Date: Wed, 25 Apr 2012 17:46:22 -0700 From: Chris Cowart <ccowart@bitgravity.com> To: freebsd-net@freebsd.org Subject: Kernel panic when using deprecated prefix on stf(4) Message-ID: <20120426004621.GB1315@netops-194.sfo1.bitgravity.com>
next in thread | raw e-mail | index | archive | help
--+g7M9IMkV8truYOl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hello,=20
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=20
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 =3D 1; apic id =3D 02
| fault virtual address =3D 0x420
| fault code =3D supervisor write data, page not present
| instruction pointer =3D 0x20:0xffffffff805013bc
| stack pointer =3D 0x28:0xffffff80000438b0
| frame pointer =3D 0x28:0xffffff80000438d0
| code segment =3D base 0x0, limit 0xfffff, type 0x1b
| =3D DPL 0, pres 1, long 1, def32 0, gran 1
| processor eflags =3D interrupt enabled, resume, IOPL =3D 0
| current process =3D 12 (swi4: clock)
| trap number =3D 12
| panic: page fault
| cpuid =3D 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 =3D 0xffffffff805013bc, rsp =3D 0xffffff80000438b0, rbp=
=3D 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 =3D 0, rsp =3D 0xffffff8000043d30, rbp =3D 0 ---
| Uptime: 57s
| Fatal trap 12: page fault while in kernel mode
| cpuid =3D 1; apic id =3D 02
| fault virtual address =3D 0x420
| fault code =3D supervisor write data, page not present
| instruction pointer =3D 0x20:0xffffffff805013bc
| stack pointer =3D 0x28:0xffffff80000438b0
| frame pointer =3D 0x28:0xffffff80000438d0
| code segment =3D base 0x0, limit 0xfffff, type 0x1b
| =3D DPL 0, pres 1, long 1, def32 0, gran 1
| processor eflags =3D interrupt enabled, resume, IOPL =3D 0
| current process =3D 12 (swi4: clock)
| trap number =3D 12
| panic: page fault
| cpuid =3D 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 =3D 0xffffffff805013bc, rsp =3D 0xffffff80000438b0, rbp=
=3D 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 =3D 0, rsp =3D 0xffffff8000043d30, rbp =3D 0 ---
| Uptime: 5d4h44m38s
| Fatal trap 12: page fault while in kernel mode
| cpuid =3D 1; apic id =3D 02
| fault virtual address =3D 0x3e0
| fault code =3D supervisor write data, page not present
| instruction pointer =3D 0x20:0xffffffff8050d37d
| stack pointer =3D 0x28:0xffffff80001cc510
| frame pointer =3D 0x28:0xffffff80001cc530
| code segment =3D base 0x0, limit 0xfffff, type 0x1b
| =3D DPL 0, pres 1, long 1, def32 0, gran 1
| processor eflags =3D interrupt enabled, resume, IOPL =3D 0
| current process =3D 1410 (ping6)
| trap number =3D 12
| panic: page fault
| cpuid =3D 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 =3D 0xffffffff8050d37d, rsp =3D 0xffffff80001cc510, rbp=
=3D 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 =3D 0x800a5b64c, rsp =3D 0x=
7fffffffe5e8, rbp =3D 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,
--=20
Chris Cowart
Lead Network Engineer
BitGravity, Inc.
A subsidiary of Tata Communications, Ltd.
--+g7M9IMkV8truYOl
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (Darwin)
iQIcBAEBAgAGBQJPmJrdAAoJELel3ONI9pMK8rcP/jrXNVC/HVV6Jrj4YI5Ayso3
BD3KRVoX8F87uv56gNjsv+wvKFCt2jxrmJCaNUpUB+a6lzUTSJfPu+Skwo5WZFxB
tk5oVCQ4noQy4vZF2KyWoYRNxocsfjGZAVANVDIUfTS3oRe2lJR2hh1LNJKJA11E
PekiIshaKdoamZNMegQbBBm2Yu9zzCG/tXZZXLvlao+/Cegkb97Do+pu6KoAgwRo
V5aNvzCuv/LvEQ2p4JW9R+Z8qmLrTKQamGeiPNOEcCsk5Dq947a0HPs79KqkfCnT
VhPYL/qmHfahDqppL2zcplMnC8Hqu34eQSemEm5oIHHeTnMp6Q32WF5098Z3/RwS
k7CHnYKLmx9bC03MfBxBt7nbY4EnQqd8mQRAq9HwMy6brEciN5yAZeP/O9ZtTuV/
pLKNopQBdWKh3T/nbcc64PTUIa3hJcHn/GzLwReVUzPH1likVV4pZpgOnP3qQLWz
IoVWeWq2/hCQpsMk9MGFpPGoy2IEh2jGlK2M2Lvarbg6qpTIGWxClYj/xbsYj7FQ
jKCKmEm0DQMraehoXHBQ1NLvdIDgzKm+BErZ7bf5NRGi2bykZaHiANX2Q/7MMh2s
hP7pY2w/5z5WoWNKu7pKh+kb4zT7UkazhN4Q+KW2RlVyhqOkmMi55dVYl2ZfwYQ2
xCyhzm4kDXMaij484wR2
=ejxn
-----END PGP SIGNATURE-----
--+g7M9IMkV8truYOl--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120426004621.GB1315>