From owner-svn-src-all@freebsd.org Sat Apr 9 15:27:36 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B6BAB08FE1; Sat, 9 Apr 2016 15:27:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 18EE51DED; Sat, 9 Apr 2016 15:27:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id ECED8B97E; Sat, 9 Apr 2016 11:27:34 -0400 (EDT) From: John Baldwin To: "Bjoern A. Zeeb" Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r297742 - head/sys/netinet Date: Sat, 09 Apr 2016 06:53:37 -0700 Message-ID: <5630207.6cr5Ycyqbh@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <201604091205.u39C5Oks041429@repo.freebsd.org> References: <201604091205.u39C5Oks041429@repo.freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sat, 09 Apr 2016 11:27:35 -0400 (EDT) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.21 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: Sat, 09 Apr 2016 15:27:36 -0000 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