Jool 3.5.0. NAT64 only. Reserved memory grew from 709 to 1655 megabytes in 10 days. The leak doesn't seem that fast but might be exploitable.
/proc/slabinfo suggests the objects being leaked are larger than 96 bytes and smaller or equal than 128.
Improve object "tracker"
Was only keeping track of kmallocs; was ignoring kmem caches.
It seems that #229 is a kmem cache leak so I had to improve the
I could easily reproduce this bug on 3.5.0 by pushing 1 Gbps through Jool: kmalloc-128 and free's buff/cache raised quickly. Then I wanted to have a glimpse of this commit: they are still raising but far more slowly than before. I enabled the kmemleak and gathered some info: I send a file containing the report to email@example.com - I hope it can help you.
Thanks! Will keep this tool handy for next time; this output led me to the problem right away.
Wow, what an embarrassing mistake.
Flood pinging. It still seems to be leaking something, but at a much slower rate.
Patch memory leak during v4 UDP/ICMP packet handling.
A session was leaking during the translation of every such packet.
Also added a bunch of mess to monitor memory leaks when we want to
Ok, I don't see any more leaks. Will monitor it for two more days and then release 3.5.1.
Patch memory leak during RFC 6056's F() function.