10.1-BETA2 possible kernel memory leak in routing table

[Rumen Telbizov]

Hello everyone,

Alexander, Gleb: good news guys. The problem seems to be resolved! Good
job.Here's what I have.

1. I upgraded the backup firewall to 10-STABLE (r272435), applied Gleb's
patch of pf_table.c and rebuilt. Just as reported by Gleb, the leak seemed
to be reduced but it was still present and leaked a little bit of memory
upon every PF reload.

2. In addition to 1) I applied the second patch from Alexander on radix.c
and rebuilt the kernel. After the reboot it seems like the amount of memory
consumed by the routetbl grows a little bit temporarily after reload and
then drops back to the previous, stable amount shortly after.

3. This is how I tested it with:
Just after boot I checked vmstat -m | grep routetbl
     routetbl   606   170K       -     4334  32,64,128,256,512,2048

Then I ran a tight loop of reloading the ruleset (and all tables) for a
while:
while true; do pfctl -f /etc/firewall/pf.conf;  done

The memory output while the loop was still running looked something like
this:
...
     routetbl  5166  2387K       - 33177467  32,64,128,256,512,2048
     routetbl  5358  2483K       - 33190813  32,64,128,256,512,2048
     routetbl  5598  2603K       - 33202561  32,64,128,256,512,2048
     routetbl  5870  2739K       - 33214365  32,64,128,256,512,2048
     routetbl  5634  2638K       - 33226099  32,64,128,256,512,2048
     routetbl  6286  2947K       - 33239443  32,64,128,256,512,2048
     routetbl  6510  3059K       - 33251175  32,64,128,256,512,2048
     routetbl  6750  3179K       - 33262925  32,64,128,256,512,2048
     routetbl  4622  2115K       - 33274645  32,64,128,256,512,2048
     routetbl  4910  2259K       - 33286441  32,64,128,256,512,2048
     routetbl  3582  1658K       - 33298175  32,64,128,256,512,2048
     routetbl  5326  2467K       - 33311519  32,64,128,256,512,2048
...
after I stopped the reload loop and waited a minute the routetbl memory
pool went back to previous state
     routetbl   606   170K       - 35615574  32,64,128,256,512,2048

I assume this delay is normal and is simply the kernel freeing memory after
it gets "cold".

I will leave this machine running and reloading the ruleset every 30
seconds as intended in carp backup mode and will report any potential
problems back here. Aside from that I think we're all good. The problem
seems solved.

Gleb, Alexander, thank you very much for your help. I appreciate your quick
response in providing patches for this problem. I hope those 2 patches get
tested by more people and get MFC'ed into 10-STABLE soon.

Regards,
-- 
Rumen Telbizov
Unix Systems Administrator <http://telbizov.com>