From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 10:37:44 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0115B5EA; Fri, 21 Nov 2014 10:37:43 +0000 (UTC) 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 A7FB1BA9; Fri, 21 Nov 2014 10:37:43 +0000 (UTC) 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 937EB25D385E; Fri, 21 Nov 2014 10:37:33 +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 AF2B1C76FDF; Fri, 21 Nov 2014 10:37:32 +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 LRip8V1tjkoL; Fri, 21 Nov 2014 10:37:31 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id BD23BC76FDA; Fri, 21 Nov 2014 10:37:29 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: VIMAGE UDP memory leak fix From: "Bjoern A. Zeeb" In-Reply-To: Date: Fri, 21 Nov 2014 10:37:25 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9300CB5F-6140-4C49-B026-EB69B0E8B37E@FreeBSD.org> References: <20141121002937.4f82daea@x23> To: "Robert N. M. Watson" X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , FreeBSD Net , Marko Zec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 10:37:44 -0000 On 21 Nov 2014, at 08:25 , Robert N. M. Watson = wrote: >=20 > On 20 Nov 2014, at 23:29, Marko Zec wrote: >=20 >>> Can folks take a look at this? >>>=20 >>> https://reviews.freebsd.org/D1201 >>=20 >> All UMA zones used in the network stack have been marked as >> UMA_ZONE_NOFREE for ages, probably for a reason, so perhaps it might >> not hurt to provide more insight why and how it suddenly became safe = to >> remove that flag? >=20 > Historically, this was (if I recall) a property of the way data was = exported for netstat, which depended on memory stability of various data = types. We have worked quite hard to remove the causes of those sorts of = dependencies by introducing stronger reference and memory ownership = models throughout the stack -- in the case of inpcbs, for example, we = introduced a true reference model during the multiprocessing scalability = work (which, it should be pointed out, was enormously painful and took = years to shake the bugs out of due to complexity/subtlety). It may be = that it is now safe to remove UMA_ZONE_NOFREE for some of the types = where it was previously required -- but it's definitely something you = want to do intentionally and in the context of a careful analysis to = convince yourself that all the causes have been addressed. A fair amount = of stress testing in low-memory conditions wouldn't hurt either... I had convinced myself for UDP many years ago that it was ok to remove = it. People have touched the code however so it=92s definitively worth = re-checking again. For TCP we clearly cannot do it (yet, and couldn=92t back then). But = TCP was the only of the few cases I had left unfixed back then. Can=92t = remember what the others were (was like 3 or 4 of them; could also be = some of the fixes were indeed committed back then. =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983