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:

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.

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
assertion.

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
memory.

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
system.

Also haven't tested/checked for other impacts / rechecked in SMP,
etc.