DragonFly bugs List (threaded) for 2008-03
Re: panic: assertion: _ifac->ifa_magic == IFA_CONTAINER_MAGIC in _IFAFREE
On Mon, Mar 17, 2008 at 09:59:52AM +0800, Sepherosa Ziehau wrote:
> On Mon, Mar 17, 2008 at 3:53 AM, Matthew Dillon
> <email@example.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
> 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.