forking locked memory generates panic
Reasoning about panic's generated by running gpg-agent as root led me to suspect
that forking a locked memory page generates a panic. The attached program verifies
this theory. Execution/Backtrace is as follows:
panic: assertion "LWKT_TOKEN_HELD_ANY(vm_object_token(object))" failed in vm_page_insert at /usr/src/sys/vm/vm_page.c:915
cpuid = 0
Trace beginning at frame 0x57730a20
panic(ffffffff,0,82bcc1c,57730a54,54ad4850) at 0x80ed8e3
panic(82bcc1c,8303b20,8306b2d,830625d,393) at 0x80ed8e3
vm_page_startup(506248b0,57738834,0,0,0) at 0x828e2e9
vm_page_alloc(57738834,0,0,1,5536d0e0) at 0x82915e7
vm_fault_copy_entry(5536d0e0,5536e460,871e398,871d984,28156000) at 0x827e47b
vmspace_fork(5536e460,81077d9,54fe7130,1c,54fe7130) at 0x8285bec
vm_fork(54fe7358,54fe70d8,40000014,871e2a8,54fe7348) at 0x82812b6
fork1(5766d160,40000014,57730c30,40400000,5766d160) at 0x80dc171
sys_fork(57730c7c,57730c8c,8,5536e460,871dee8) at 0x80dc47e
syscall2(57730d40,3,57730cec,0,0) at 0x82b1ab6
user_trap(57730d40,1,57730d40,54ad4b00,28464360) at 0x82b1d3c
go_user(57730d38,0,0,7b,0) at 0x82b2261
CPU0 stopping CPUs: 0x00000002
Stopped at 0x82aefb6: movb $0,0x874f7d4
My preliminary effort at debugging this seems to indicate that vm objects passed
into vmspace_fork are not properly locked, which results in the assertion failing -
however I am unfortunately not well versed enough in the VM subsystem to track this
down further without significant time and my guess is that someone who is well versed
can make short work of this bug.
Did not make core/kernel images available as is easily reproducable, can do so upon request.
v184.108.40.206.gb8b49-DEVELOPMENT i386 GENERIC
v220.127.116.11.gb8b49-DEVELOPMENT i386 VKERNEL
v18.104.22.1688.g69b66-DEVELOPMENT i386 VKERNEL
and also appears to affect late-cycle 2.13-DEVELOPMENT based on my recollection of a
gpg-agent generated panic at that time, so any likely fix probably needs to be mfc'ed.
#1 Updated by c.turner1 about 4 years ago
On 02/29/12 05:33, Chris Turner via Redmine wrote:
> Reasoning about panic's generated by running gpg-agent as root led me to suspect
> that forking a locked memory page generates a panic.
Bug was reproduced on SMP/UP i386 VKernels, as well as SMP x86-64.
Attached patch seems to fix the issue for me on a UP vkernel -
basically it looks like vm_fault_copy_entry allocates a new entry
for the destination pagetable but doesn't properly lock it before
attempting to allocate an actual memory page, triggering the
The call to vm_fault_copy_entry is a special case call from
vm_map_copy_entry which is why this was only affecting locked
A second assertion was triggered in the source pagetable lookup
which follows a few lines further down which locking fixed - but
perhaps this should be locked in the caller..
... so ...
Of course - comments welcome as I'm by no means an expert on the
VM system & locking, and perhaps there are other ways to sort this
out that are more 'correct' w/r/t to the overall design of the VM
Also haven't tested/checked for other impacts / rechecked in SMP,