rogue module allocating 4G wired memory / pmap_growkernel does vm_page_alloc to get 4G wired
Shrikanth Kamath
shrikanth07 at gmail.com
Wed Jul 13 10:39:00 UTC 2016
I have this broadcom sdk module while getting loaded by a rc script
calling kldload triggers a 4G jump in the wired memory (as shown by
output of top)
# top
...
...
Mem: 77M Active, 644M Inact, 4473M Wired, 1600K Cache, 606M Buf, 2734M Free
...
Upon using dtrace I get the responsible stack trace as this one which
does most vm_page_alloc
0 10310 vm_page_alloc:entry
kernel`pmap_growkernel+0x1cc
kernel`vm_map_insert+0x3ee
kernel`vm_map_find+0x14d
kernel`link_elf_load_file+0x845
kernel`linker_load_module+0x6ec
kernel`kern_kldload+0xab
kernel`sys_kldload+0x84
kernel`amd64_syscall+0x3b6
kernel`0xffffffff805413a7
And the number of page allocations that happen in this context does
also sum up to around 4G. It showed the total page allocations that
happened in this context was
vm_page_alloc 1045039
which is approx 3.99G.
On probing a little deeper, the link_elf_load_file calls for
vm_map_find with mapspace of 20MB. This results in a call to
vm_map_findspace which I believe first checks if it can do a
contiguous allocation within the kernel_map else it goes trying to map
it beyond the kernel_map.
Probing further we see that before the call to vm_map_find the
kernel_vm_end is at the default value of kernbase at
0xffffffff80000000 The vm_map_findspace then picks the new start
address to be 0xffffffff83d68000. The call to pmap_growkernel does
grow the number of kernel page table entries to match the new end
address i.e 0xffffffff85136000 and thereby kernel_vm_end is also
adjusted to 0xffffffff85200000 from the initial default value of
0xffffffff80000000.
Is my understanding correct here that vm_map_find is unable to
allocate the 20MB mapspace requested in the kernel_map and hence calls
pmap_growkernel thereby resulting in the wired memory increase?
--
Shrikanth R K
More information about the freebsd-amd64
mailing list