DF-3523 / run.log
DF-3523 run.log — STOCK kernel (X86_64_GENERIC #0, INVARIANTS), guest dfbsd
[1] module load + baseline (vmstat -m, netgraph malloc zone):
netgraph_path 0 0 0 390M 13
netgraph_sock 0 0 0 390M 6
netgraph 4 576 0 390M 8
netgraph_hook 0 0 0 390M 8
netgraph_node 2 256 0 390M 11
netgraph_msg 1 72 0 390M 16
netgraph_apply 1 16 0 390M 1
[2] # ./pptp_leak 30000 (arm/cancel cycles; loop runs as uid 65534)
... 5000 rounds
... 10000 rounds
... 15000 rounds
... 20000 rounds
... 25000 rounds
... 30000 rounds
done: 30000 rounds (windowing=1)
[3] vmstat -m after:
netgraph_path 0 0 0 390M 58.6K
netgraph_sock 1 192 0 390M 8
netgraph 5.76K 830K 0 390M 5.76K
netgraph_hook 3 312 0 390M 12
netgraph_node 4 544 0 390M 14
netgraph_msg 1 72 0 390M 58.6K
netgraph_apply 1 16 0 390M 1
=> netgraph zone InUse 4 -> 5.76K (830K permanently leaked; the live
leaked ng_item count is 30000 -- vmstat shows only the objcache
backing allocations that never return).
[4] persistence evidence:
# kldunload ng_pptpgre
kldunload: can't unload file: Device busy (leaked node refs pin module)
second run: "name pptp0: Address already in use" (leaked refs keep the
dead node's NAME registered -- ng_unref_node's LIST_REMOVE only
happens at last ref)
[5] escalation (observed, see panic.txt): after the 30k-cycle leak, the
next netgraph control-socket creation rehashes the node idhash and
hits the DF-3514 sink:
Warning: objcache(netgraph) exhausted on cpu0!
panic: hashdestroy: hash not empty
ngc_attach() -> ng_make_node_common() -> hashdestroy()
(guest down; serial console capture in panic.txt)
[6] CONTROL run, fresh boot, identical code path with enableWindowing=0
(rack timer never armed; nothing for ng_uncallout to cancel):
baseline : netgraph Count=3 432
30000 rounds -> exit=0
after : netgraph Count=3 432 (FLAT)