From owner-svn-src-all@freebsd.org Sat Apr 9 18:31:39 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 4AD7CB08067; Sat, 9 Apr 2016 18:31:39 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 083C41323; Sat, 9 Apr 2016 18:31:38 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 2E5D825D385E; Sat, 9 Apr 2016 18:31:28 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 441CDD1F7F9; Sat, 9 Apr 2016 18:31:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id EmOwDeg6WbTm; Sat, 9 Apr 2016 18:31:25 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 882BEC7BF64; Sat, 9 Apr 2016 18:31:25 +0000 (UTC) Date: Sat, 9 Apr 2016 18:31:24 +0000 (UTC) From: "Bjoern A. Zeeb" To: John Baldwin cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r297742 - head/sys/netinet In-Reply-To: <5630207.6cr5Ycyqbh@ralph.baldwin.cx> Message-ID: References: <201604091205.u39C5Oks041429@repo.freebsd.org> <5630207.6cr5Ycyqbh@ralph.baldwin.cx> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 18:31:39 -0000 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.