Date: Sat, 18 Aug 2012 05:31:24 -0400 From: Randall Stewart <rrs@lakerest.net> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r239353 - head/sys/netinet Message-ID: <E60B43B7-21D3-421E-B631-8F0A99ACDF07@lakerest.net> In-Reply-To: <201208170826.25123.jhb@freebsd.org> References: <201208170551.q7H5pkd1025308@svn.freebsd.org> <201208170826.25123.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 17, 2012, at 8:26 AM, John Baldwin wrote: > On Friday, August 17, 2012 1:51:46 am Randall Stewart wrote: >> Author: rrs >> Date: Fri Aug 17 05:51:46 2012 >> New Revision: 239353 >> URL: http://svn.freebsd.org/changeset/base/239353 >>=20 >> Log: >> Ok jhb, lets move the ifa_free() down to the bottom to >> assure that *all* tables and such are removed before >> we start to free. This won't protect the Hash in ip_input.c >> but in theory should protect any other uses that *do* use locks. >=20 > Eh, this is just a nop unless there is a reference counting bug. Only = the=20 > last reference would free the memory if the reference count is = correct, so=20 > this is just adding obfuscation by moving the ifa_free() away from the=20= > associated TAILQ_REMOVE(). >=20 Well there is definitely a reference counting but in here somewhere = then. And as far as "obfuscation" of the code, it was not obvious to me when first = looking at the code and it should have been since I looked at this earlier. So = without a more detailed comment I think its obscure anyway ;-) I will get SQA another INVARIANT load and see if they can recreate it = for me. The load they had when they first produced this was *supposed* to be = INVARIANT but after a bit of research on my part I find they were running the non-invariant, = which explains why things locked up instead of the assert triggering.. sigh. Note that in the main FreeBSD sources however, the fact that ip_input.c = does *not* lock when it looks at the hash table these lines are removing from here means = there is still a potential for a crash. I have a fix for this that does not require the lock, when = I get a moment I will send it your way=85 you have seen part of it ;-) R > --=20 > John Baldwin >=20 ------------------------------ Randall Stewart 803-317-4952 (cell)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E60B43B7-21D3-421E-B631-8F0A99ACDF07>