DragonFlyBSD

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:

dfdev01# ./forklock
pre-lock: 0x28180070
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
Debugger("panic")

CPU0 stopping CPUs: 0x00000002
stopped
Stopped at 0x82aefb6: movb $0,0x874f7d4
db>

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.

Tested against:

v3.1.0.98.gb8b49-DEVELOPMENT i386 GENERIC
v3.1.0.98.gb8b49-DEVELOPMENT i386 VKERNEL
v3.1.0.258.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.

Cheers,

- Chris