panic: assertion: _ifac->ifa_magic == IFA_CONTAINER_MAGIC in _IFAFREE

[Sepherosa Ziehau]

On Tue, Mar 18, 2008 at 8:53 AM, YONETANI Tomokazu <qhwt+dfly at les.ath.cx> wrote:
> On Mon, Mar 17, 2008 at 09:59:30PM +0800, Sepherosa Ziehau wrote:
>  > On Mon, Mar 17, 2008 at 11:06 AM, YONETANI Tomokazu
>  > <qhwt+dfly at les.ath.cx> wrote:
>  > > On Sun, Mar 16, 2008 at 08:09:17PM +0800, Sepherosa Ziehau wrote:
>  > >  > On Sun, Mar 16, 2008 at 6:07 PM, YONETANI Tomokazu <qhwt+dfly at les.ath.cx> wrote:
>  > >  > > Hello.
>  > >  > >  Just caught a panic while playing with NFS mounted git tree
>  > >  > >  (but I cannot reliably reproduce it after that):
>  > >  >
>  > >  > dst address of a UDP packet is changed, which changes port/addr hash
>  > >  > too, but old route entry was not allocated on the current CPU.  Since
>  > >  > the box only contains 2 CPUs, after the l{port,addr}/f{port,addr}
>  > >  > hash, the problem probably will not show itself ;).  Please run
>  > >  > following test program several times and then unload the NIC module to
>  > >  > see whether you could reproduce the problem (if you have TCP
>  > >  > connections too, you will have to wait 2MSL):
>  > >  > http://leaf.dragonflybsd.org/~sephe/test_udp.c
>  > >
>  > >  I've been trying to reproduce it but so far unsuccessful...
>  >
>  > I have changed this test program a little bit.  Run it in following way:
>  > ./test_udp remote_ip
>  >
>  > If it paused, then on the other term:
>  > ifconfig iface_local down
>  > And kill test_udp, if you don't have TCP connection, the panic should
>  > happen immediately.
>
>  Yes!  But this time at a different place:

This panic is not what I had expected though :)  Could you get a coredump?

>  #9  0xc0328dc2 in rtrequest1 (req=11, rtinfo=0xca77ec9c, ret_nrt=0xca77ecf0)
>     at /home/dfly/current/sys/net/if_var.h:445
>  #10 0xc032915f in rtrequest (req=11, dst=0xca77ed14, gateway=0x0, netmask=0x0,
>     flags=0, ret_nrt=0xca77ecf0) at /home/dfly/current/sys/net/route.c:637
>  #11 0xc0329386 in _rtlookup (dst=0xca77ed14, generate_report=1, ignore=0)
>     at /home/dfly/current/sys/net/route.c:275
>  #12 0xc0343642 in arplookup (addr=30085292, create=1, proxy=-1067129044)
>     at /home/dfly/current/sys/net/route.h:364
>  #13 0xc034371a in arp_update_oncpu (m=<value optimized out>, saddr=30085292,
>     create=28790, dologging=0) at /home/dfly/current/sys/netinet/if_ether.c:563
>  #14 0xc0343f66 in arp_update_msghandler (netmsg=0xc985bd08)
>     at /home/dfly/current/sys/netinet/if_ether.c:877
>  #15 0xc03284a2 in rtable_service_loop (dummy=0x0)
>     at /home/dfly/current/sys/net/route.c:178
>  #16 0xc02c12e5 in lwkt_deschedule_self (td=Cannot access memory at address 0x8
>
> )
>     at /home/dfly/current/sys/kern/lwkt_thread.c:214
>
>  So, can I start testing your patch, or do you need an update to it?

Nah, it is a workaround.  You can use it to prevent the panic upon
rtfree.  I will work out a real fix by patching various udp functions
I mentioned when I get back home.

Best Regards,
sephe

-- 
Live Free or Die