VIMAGE UDP memory leak fix

[Marko Zec]

On Fri, 21 Nov 2014 10:37:25 +0000
"Bjoern A. Zeeb" <bz at FreeBSD.org> wrote:

> 
> On 21 Nov 2014, at 08:25 , 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...
> 
> I had convinced myself for UDP many years ago that it was ok to
> remove it.  People have touched the code however so it’s definitively
> worth re-checking again.
> 
> For TCP we clearly cannot do it (yet, and couldn’t back then).   But
> TCP was the only of the few cases I had left unfixed back then.
> Can’t remember what the others were (was like 3 or 4 of them;  could
> also be some of the fixes were indeed committed back then.

Now that we've found ourselves in this discussion, I'm really
becoming curious why exactly do we need UMA_ZONE_NOFREE for network
stack zones at all?   Admittedly, I always thought that the primary
purpose of UMA_ZONE_NOFREE was to prevent uma_reclaim() from paging out
_used_ zone pages, but reviewing the uma code reveals that this might
not be the case, i.e. that NOFREE only prevents _unused_ pages to be
freed by uma_reclaim().

Moreover, all uma_zalloc() calls as far as I can see are flagged as
M_NOWAIT and are followed by checks for allocation failures, so that
part seems to be covered.

So, what's really the problem which UMA_ZONE_NOFREE flagging is supposed
to solve these days? (you claim that we clearly need it for TCP - why)?

Marko