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

[YONETANI Tomokazu <qhwt+dfly@xxxxxxxxxx>]

On Mon, Mar 17, 2008 at 09:59:52AM +0800, Sepherosa Ziehau wrote:
> On Mon, Mar 17, 2008 at 3:53 AM, Matthew Dillon
> <dillon@apollo.backplane.com> wrote:
> >
> >  :Hello.
> >
> > :Just caught a panic while playing with NFS mounted git tree
> >  :(but I cannot reliably reproduce it after that):
> >  :
> >  :panic: assertion: _ifac->ifa_magic == IFA_CONTAINER_MAGIC in _IFAFREE
> >  :mp_lock = 00000001; cpuid = 1
> >  :               :
> >  :and the backtrace below the panic is as follows:
> >  :
> >  :#9  0xc032907e in rtfree (rt=0xc116ca60)
> >  :    at /home/dfly/current/sys/net/if_var.h:469
> >  :#10 0xc034e8ed in ip_output (m0=0xcc2fd100, opt=0x0, ro=0xc9ebde3c,
> >  :    flags=<value optimized out>, imo=0x0, inp=0xc9ebde00)
> >  :    at /home/dfly/current/sys/netinet/ip_output.c:245
> >
> >     I assume IFA_CONTAINER_MAGIC is a sanity check you added somewhere
> >     in your local tree?  Its a good idea but probably catches the
> 
> Nah, it is in the cvs repos.  I added that when parallelize ifnet.if_addrhead.
> 
> >     bug too late.
> 
> It could catch problems like freeing/allocating rtentry on different
> CPU (e.g. the TCP connection problem, I fixed before release).
> 
> The problem YONETANI had seen is caused by allocating/freeing rtentry
> on different CPU:
> 1) connect(2) is not called on UDP socket
> 2) One UDP datagram was sent to dst1/port1 on the socket, given
> port/addr hash dispatches the sending to CPUX.  rtentry was allocated
> on CPUX and was installed/referenced in this socket's inpcb
> 3) Sometime later, the rtentry is removed from radix tree, but the UDP
> socket is not closed.  Given it contains the last reference of the
> rtentry
> 4) Another UDP datagram is sent to dst2/port2 on the socket, port/addr
> hash dispatches the sending to CPUY.  Since dst1 != dst2 then rtentry
> in socket's inpcb would be freed on CPUY.  Thus the panic happens

Oh, I forgot to mention that the last command before the panic was df
(shown as thread ID 1), if that matters.

Cheers.