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

["Sepherosa Ziehau" <sepherosa@xxxxxxxxx>]

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

Best Regards,
sephe

-- 
Live Free or Die