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 PROTECTED]> 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.
