VIMAGE UDP memory leak fix

Robert N. M. Watson rwatson at FreeBSD.org
Fri Nov 21 10:21:01 UTC 2014


On 21 Nov 2014, at 10:19, Robert N. M. Watson <rwatson at FreeBSD.ORG> 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.
> 
> 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


More information about the freebsd-net mailing list