Date: Sat, 09 Apr 2016 06:53:37 -0700 From: John Baldwin <jhb@freebsd.org> To: "Bjoern A. Zeeb" <bz@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: <5630207.6cr5Ycyqbh@ralph.baldwin.cx> In-Reply-To: <201604091205.u39C5Oks041429@repo.freebsd.org> References: <201604091205.u39C5Oks041429@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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? -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5630207.6cr5Ycyqbh>