On 11-02-18, Daniel Kahn Gillmor wrote:
> Hi Baptiste--
> 
> On Sun 2018-02-11 14:48:37 +0100, Baptiste Jonglez wrote:
> 
> > On a x86_64 VM with quite a lot of Wireguard traffic (~300 GB per day), I
> > am seeing a memory leak with wireguard 0.0.20171221-5.  System is Debian
> > stretch, kernel 4.9.65-3+deb9u2, wireguard package from unstable.
> 
> oof, thanks for this report, and for the really useful graph
> visualization.
> 
> it's troubling that the changes correlated with the memleak are both a
> kernel upgrade *and* a wireguard upgrade, since that kind of conflation
> might be difficult to tease apart.

Yes, I *think* it's related to wireguard and not the kernel upgrade (since
far more people use the kernel than wireguard), but I'm not 100% sure.

And indeed, we could imagine it to be an issue in wireguard related to the
newer kernel...

> i'm curious from the graph -- do you know what happened at the start of
> week 6 where there's a sawtooth?

Actually, the amount of "slab_cache" didn't change at that point, it's
just the amount of application memory that dropped a bit.  I looked at the
logs, some userspace processes were being killed by the OOM-killer.

> If you still see a leak with the latest wireguard, i'd appreciate if you
> could test the current kernel with 0.0.20171011-1 to see whether you can
> isolate the problem to the kernel.  i'm not recommending running
> 0.0.20171011-1 for the long term, but it should still be wire-format
> compatible with other implementations and will help with debugging to
> have the comparison.

Excellent suggestion!

It does look like 0.0.20180202-1 still has the memleak.  I will leave it
running a few more days to be certain, and then switch to 0.0.20171011-1.

Baptiste