VIMAGE UDP memory leak fix

[Marko Zec]

On Fri, 21 Nov 2014 08:25:48 +0000
"Robert N. M. Watson" <rwatson at FreeBSD.org> wrote:

> 
> On 20 Nov 2014, at 23:29, Marko Zec <zec at fer.hr> wrote:
> 
> >> Can folks take a look at this?
> >> 
> >> https://reviews.freebsd.org/D1201
> > 
> > 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?
> 
> 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...

If data stability for userland export was the only factor mandating
UMA_ZONE_NOFREE flagging then indeed it may be safe to remove that
flag, since the VNET / prison referencing model guarantees that no VNET
teardown can commence as long as there are processes, sockets or ifnets
attached to a particular VNET.  But as you said that change would
affect both VIMAGE and non-VIMAGE builds, so extensive testing would be
warranted here.

Nevertheless, I'd prefer most of network stack UMA zones to be
de-virtualized, at least those which cannot cause interference between
VNETs, and that excludes syncache, reassembly, hostcache and the likes.
De-virtualization doesn't require touching the UMA_ZONE_NOFREE flag, so
doesn't affect non-VIMAGE builds.  Any objections to that approach?

Marko