Date: Fri, 21 Nov 2014 10:19:18 +0000 From: "Robert N. M. Watson" <rwatson@FreeBSD.org> To: Marko Zec <zec@fer.hr> Cc: Craig Rodrigues <rodrigc@freebsd.org>, FreeBSD Net <freebsd-net@freebsd.org>, "Bjoern A.Zeeb" <bz@freebsd.org> Subject: Re: VIMAGE UDP memory leak fix Message-ID: <8FC3AD80-7605-4D88-BF4E-D33E449B30FF@FreeBSD.org> In-Reply-To: <20141121104538.5eed0567@x23> References: <CAG=rPVehky00X4MuQQ-_Oe5ezWg52ZZrPASAh9GBy7baYv78CA@mail.gmail.com> <20141121002937.4f82daea@x23> <A4D676B3-6C50-47F7-8CFD-50B44FF4BE98@FreeBSD.org> <20141121095847.11601640@x23> <36975BCB-1F45-4128-9FB6-004F07489E53@FreeBSD.org> <A8D54927-077E-4FFD-9EBE-1E486621F196@FreeBSD.org> <20141121104538.5eed0567@x23>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21 Nov 2014, at 09:45, Marko Zec <zec@fer.hr> wrote: >> And, to respond to your more general comment: I agree that a decision >> about removing the NOFREE flag should be made independently of >> choices about devirtualisation. The former probably should be sorted >> out at this point, as eliminating NOFREE zones has more general >> benefits to the kernel, but it would be nice not to depend on that to >> resolve other problems. It could be that a few of us scratching our >> heads for a few hours each can resolve whether NOFREE can now be >> safely removed, in which case we should do so (and then allow quite a >> lot of baking time before it ships in a release). >=20 > 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. Robert=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8FC3AD80-7605-4D88-BF4E-D33E449B30FF>