Bug #2320
closed
forking locked memory generates panic
0%
Description
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
Files
Updated by c.turner1 almost 13 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
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.
Cheers,
- Chris
Updated by c.turner1 almost 13 years ago
- Status changed from New to Resolved
Fixed in 54113f7 dcdeb2 269be04,
MFC'ed to 3.0.x in: 6ff27fd c789dd4 e9bd102
Updated by c.turner1 almost 13 years ago
- Status changed from Resolved to Closed
swildner: also note that "resolved" doesn't close an issue in the tracker. only "closed" does
-> closed.