From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 10:21:01 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 785C51B3; Fri, 21 Nov 2014 10:21:01 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 4E785A6B; Fri, 21 Nov 2014 10:21:01 +0000 (UTC) Received: from [10.108.126.128] (unknown [46.233.116.131]) by cyrus.watson.org (Postfix) with ESMTPSA id 251B046B64; Fri, 21 Nov 2014 05:20:58 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: VIMAGE UDP memory leak fix From: "Robert N. M. Watson" In-Reply-To: <8FC3AD80-7605-4D88-BF4E-D33E449B30FF@FreeBSD.org> Date: Fri, 21 Nov 2014 10:20:56 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <8DBEE2B1-3801-4722-B648-BD5B7B04D4C6@FreeBSD.org> References: <20141121002937.4f82daea@x23> <20141121095847.11601640@x23> <36975BCB-1F45-4128-9FB6-004F07489E53@FreeBSD.org> <20141121104538.5eed0567@x23> <8FC3AD80-7605-4D88-BF4E-D33E449B30FF@FreeBSD.org> To: Marko Zec X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , FreeBSD Net , "Bjoern A.Zeeb" 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:21:01 -0000 On 21 Nov 2014, at 10:19, Robert N. M. Watson = wrote: >> The important thing here is not to loose the momentum and energy = which >> Craig is putting in cleaning up VIMAGE, so if we take the route of >> eliminating the UMA_ZONE_NOFREE flag (or not), that should be decided >> with rough consensus and without too much delays, and without too = much >> bikeshed re. what could be nice to have in some distant future and >> whatnot. The current goal is cleaning up VIMAGE and making it >> palatable for 11.0, without taking too much risk at breaking other >> things. I'm strongly opposed to even thinking aloud about any new >> VNET-related features or concepts until VIMAGE finally becomes = enabled >> in /head. >=20 > In the long list of things that are hard in operating systems, = reasoning about data-structure reference counting and memory models in = the presence of concurrency is pretty high on the list. I think you = would not want to rush that sort of thing, and hence my feeling that you = want to disentangle these two concerns. Throwing the switch on the = UMA_ZONE_NOFREE flag setting is easy, but debugging race conditions = involving use-after-free in the field is incredibly hard. If you can = avoid depending on this, especially if we throw the switch and then = discover in a few weeks or months that it wasn't as simple as we = thought, then you put other more concrete goals substantially less at = risk. We can go away and think hard about UMA_ZONE_NOFREE for a few = weeks, and follow up, but I recommend you find another solution in the = mean time if you are worried about stalling VIMAGE cleanups. (Alternatively, as I suggested in an earlier e-mail, you can convince us = that you've done that analysis already by citing the revision history = where all the pertinent problems were resolved, along with an informal = argument that no other problems remain, which would mean much less = waiting for us to try to make that argument for you. However, making the = NOFREE change without going through that process is a recipe for = disaster that we'd all rather avoid!) Robert=