From owner-svn-src-all@FreeBSD.ORG Thu Aug 16 22:34:29 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F6E710657C3; Thu, 16 Aug 2012 22:34:29 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (lakerest.net [70.155.160.98]) by mx1.freebsd.org (Postfix) with ESMTP id 30F908FC0C; Thu, 16 Aug 2012 22:34:28 +0000 (UTC) Received: from [10.1.1.141] (bsd3.lakerest.net [70.155.160.101]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id q7GMXC1F090620 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 16 Aug 2012 18:33:12 -0400 (EDT) (envelope-from rrs@lakerest.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Randall Stewart In-Reply-To: <201208161534.42012.jhb@freebsd.org> Date: Thu, 16 Aug 2012 18:33:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <896011BA-5F0C-4371-A9D2-6E96283380E0@lakerest.net> References: <201208161755.q7GHtHHZ048693@svn.freebsd.org> <201208161534.42012.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1278) Cc: svn-src-head@freebsd.org, Randall Stewart , svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r239334 - head/sys/netinet X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 22:34:29 -0000 On Aug 16, 2012, at 3:34 PM, John Baldwin wrote: > On Thursday, August 16, 2012 1:55:17 pm Randall Stewart wrote: >> Author: rrs >> Date: Thu Aug 16 17:55:16 2012 >> New Revision: 239334 >> URL: http://svn.freebsd.org/changeset/base/239334 >>=20 >> Log: >> Its never a good idea to double free the same >> address. >>=20 >> MFC after: 1 week (after the other commits ahead of this gets = MFC'd) >>=20 >> Modified: >> head/sys/netinet/in.c >>=20 >> Modified: head/sys/netinet/in.c >>=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> --- head/sys/netinet/in.c Thu Aug 16 17:27:11 2012 = (r239333) >> +++ head/sys/netinet/in.c Thu Aug 16 17:55:16 2012 = (r239334) >> @@ -573,7 +573,7 @@ in_control(struct socket *so, u_long cmd >> } >> TAILQ_REMOVE(&ifp->if_addrhead, &ia->ia_ifa, ifa_link); >> IF_ADDR_WUNLOCK(ifp); >> - ifa_free(&ia->ia_ifa); /* if_addrhead = */ >> +/* ifa_free(&ia->ia_ifa); - Double free?? */ /* if_addrhead = */ >=20 > This isn't a double free. This is dropping a reference count. In = this case=20 > as the comment suggests, it is removing the reference held by the per- > interface if_addrhead list that it was just removed from two lines = above. =20 > Later in the function when ifa_free() is invoked: >=20 > LIST_REMOVE(ia, ia_hash); > IN_IFADDR_WUNLOCK(); > ... > ifa_free(&ia->ia_ifa); /* in_ifaddrhead = */ >=20 > It is dropping the reference held by the in_ifaddrhead list which the = ifa > was removed from by the above LIST_REMOVE(). Are you seeing a panic = or > refcount underflow or some such? >=20 No panic, I wish I were so lucky, I had a lockup/fault at: in_gif.c line 410 (this is 9 stable) ----------------------- IN_IFADDR_RLOCK(); TAILQ_FOREACH(ia4, &V_in_ifaddrhead, ia_link) { if ((ia4->ia_ifa.ifa_ifp->if_flags & IFF_BROADCAST) =3D=3D= 0) <------fault in kernel HERE continue; if (ip->ip_src.s_addr =3D=3D = ia4->ia_broadaddr.sin_addr.s_addr) { IN_IFADDR_RUNLOCK(); return 0; } } IN_IFADDR_RUNLOCK(); ------------------------ I went through and made sure first that every reference using = V_in_ifaddrhead was properly locking, and they were. The only thing I could find is = this. From the instructions I could see in the assembly the ia4->ia_ifa.ifa_ifp was = NULL. And thus caused a deref of a NULL pointer. Hmm, it takes two days of pounding to get this by the way. We are using = a Shenick with our proxy that is adding and deleting addresses on a somewhat regular = basis while traffic is flowing ;-0 Something that not a lot of folks do obviously=85 not sure why I did not get into DDB, two CPU's faulted at the same time though.. also the HP's = that this thing was running on are not known for being kind on getting into = even DDB ;-( Be glad when we get them all replaced with iX systems ;-) R > --=20 > John Baldwin >=20 ------------------------------ Randall Stewart 803-317-4952 (cell)