[PATCH] Fix in6p_leave_group() panic by misbehaving apps - VLC
SAP service discovey still panics kernel
Bruce Simpson
bms at incunabulum.net
Fri Jul 31 03:57:31 UTC 2009
Mattia Rossi wrote:
> (kgdb)
> bt
>
> #0 doadump () at
> pcpu.h:246
>
> #1 0xc088c5c7 in boot (howto=260) at
> /usr/src/sys/kern/kern_shutdown.c:419
> #2 0xc088c8f2 in panic (fmt=Variable "fmt" is not
> available. ) at
> /usr/src/sys/kern/kern_shutdown.c:575
>
> #3 0xc0bc75b3 in trap_fatal (frame=0xc73797fc, eva=8) at
> /usr/src/sys/i386/i386/trap.c:933 #4 0xc0bc7810 in
> trap_pfault (frame=0xc73797fc, usermode=0, eva=8) at
> /usr/src/sys/i386/i386/trap.c:846 #5 0xc0bc8223 in trap
> (frame=0xc73797fc) at
> /usr/src/sys/i386/i386/trap.c:528 #6
> 0xc0baad0b in calltrap () at
> /usr/src/sys/i386/i386/exception.s:165
> #7 0xc071c9a0 in lpoutput (ifp=0xc782b400, m=0xc86f2400,
> dst=0xc7379a58, ro=0x0) at /usr/src/sys/dev/ppbus/if_plip.c:669
> #8 0xc0a39018 in nd6_output_lle (ifp=0xc782b400, origifp=0xc782b400,
> m0=0xc86f2400, dst=0xc7379a58, rt0=0x0, lle=0x0, chain=0x0) at
> /usr/src/sys/netinet6/nd6.c:1914
> #9 0xc0a3912d in nd6_output (ifp=0xc782b400, origifp=0xc782b400,
> m0=0xc86f2400, dst=0xc7379a58, rt0=0x0) at
> /usr/src/sys/netinet6/nd6.c:1691 #10 0xc0a33ac8
> in ip6_output (m0=0xc7dab500, opt=0xc0dda6a0, ro=0xc7379a50, flags=1,
> im6o=0xc7379b30, ifpp=0xc7379b50,
> inp=0x0) at
> /usr/src/sys/netinet6/ip6_output.c:905
>
> #11 0xc0a34833 in mld_dispatch_packet (m=Variable "m" is not
> available.
>
> ) at
> /usr/src/sys/netinet6/mld6.c:3074
>
> #12 0xc0a34b48 in mld_dispatch_queue (ifq=0xc7379bdc, limit=0) at
> /usr/src/sys/netinet6/mld6.c:409
>
> #13 0xc0a375e9 in mld_fasttimo () at
> /usr/src/sys/netinet6/mld6.c:1421
>
> #14 0xc0a19588 in icmp6_fasttimo () at
> /usr/src/sys/netinet6/icmp6.c:2231
>
> #15 0xc08e1d49 in pffasttimo (arg=0x0) at
> /usr/src/sys/kern/uipc_domain.c:522
>
> #16 0xc089f50c in softclock (arg=0xc0dc1b80) at
> /usr/src/sys/kern/kern_timeout.c:411
>
> #17 0xc08635eb in intr_event_execute_handlers (p=0xc755a7f8,
> ie=0xc75a0d80) at
> /usr/src/sys/kern/kern_intr.c:1165
>
> #18 0xc0864b8b in ithread_loop (arg=0xc75591d0) at
> /usr/src/sys/kern/kern_intr.c:1178
>
> #19 0xc0860e81 in fork_exit (callout=0xc0864b20 <ithread_loop>,
> arg=0xc75591d0, frame=0xc7379d38) at
> /usr/src/sys/kern/kern_fork.c:838 #20
> 0xc0baad80 in fork_trampoline () at
> /usr/src/sys/i386/i386/exception.s:270
...
>
> It really seems it has to do something with IPv6...
Actually, this backtrace lands in plip(4). Are you using a laplink cable
or similar on this system?
I believe the upper code is correct. Haven't had any other reports of
panics with other network drivers.
It may be something to do with plip's treatment of the mbuf handed off
to it; more likely it could be an interaction between the nd6 code and
the plip driver.
There have been issues with the ARP cache code, which is broadly related
to nd6, which Qing Li has been looking at; a fix was recently committed
for an issue there.
Unfortunately I don't have equipment or free time to look at the plip
issue further. Hope this helps.
cheers,
BMS
More information about the freebsd-current
mailing list