Date: Sat, 9 Apr 2016 18:31:24 +0000 (UTC) From: "Bjoern A. Zeeb" <bz@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r297742 - head/sys/netinet Message-ID: <alpine.BSF.2.00.1604091824530.83904@ai.fobar.qr> In-Reply-To: <5630207.6cr5Ycyqbh@ralph.baldwin.cx> References: <201604091205.u39C5Oks041429@repo.freebsd.org> <5630207.6cr5Ycyqbh@ralph.baldwin.cx>
index | next in thread | previous in thread | raw e-mail
On Sat, 9 Apr 2016, John Baldwin wrote: > On Saturday, April 09, 2016 12:05:24 PM Bjoern A. Zeeb wrote: >> Author: bz >> Date: Sat Apr 9 12:05:23 2016 >> New Revision: 297742 >> URL: https://svnweb.freebsd.org/changeset/base/297742 >> >> Log: >> Mfp: r296310,r296343 >> >> It looks like as with the safety belt of DELAY() fastened (*) we can >> completely tear down and free all memory for TCP (after r281599). >> >> (*) in theory a few ticks should be good enough to make sure the timers >> are all really gone. Could we use a better matric here and check a >> tcbcb count as an optimization? > > In theory, no amount of DELAY() is ever enough to close a theoretical race > window. In practice you might get lucky, but you might also panic and Yes I do understand. Thus saying a better metric should do the right thing. I am aware of the consequences of removing type stability. Should there be reports I'll make sure that DELAY becomes something more proper sooner than later. > trash user data. In the rest of the tree, we tend to prefer marking items > as NOFREE instead of this approach putting a priority on stability and > reliability over memory efficiency. > > For all of the zones that you removed NOFREE from, do you know why that was > added in the first place (e.g. which stale pointers to pcbs could be > referenced after free)? Did you verify that those conditions have been > fixed? I did check. I did check a few years ago (and I think you had reviewed that; maybe it was trouble). And the TCP bits here were the last ones that were problematic back then. With the changes from r281599 this should no longer be a problem. As for the others, a few years ago Andre already removed the NOFREE and we unconditionally made him back the change out, which was a mistake as otherwise some of these zones would have been "clean" for years. Others have had KASSERTs ensuring that on VNET stack they were actually empty.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1604091824530.83904>