Re: [PATCH] Fix in6p_leave_group() panic by misbehaving apps - VLC SAP service discovey still panics kernel

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