On 12/17/22 14:15, David Hill wrote:
ddb{3}> trace /t 0t409572
sleep_finish(ffff8000344d1fd0,1) at sleep_finish+0xfe
rw_enter(fffffd821cbcb220,21) at rw_enter+0x232
vm_map_lock_ln(fffffd821cbcb188,ffffffff81f22ed0,6e7) at
vm_map_lock_ln+0x92
uvmfault_lookup at uvmfault_lookup+0x73
uvm_fault_check(ffff8000344d22b0,ffff8000344d22e8,ffff8000344d2310) at
uvm_fault_check+0x27e
uvm_fault(fffffd821cbcb188,c005ad0000,0,2) at uvm_fault+0xfb
upageflttrap(ffff8000344d2410,c005ad0000) at upageflttrap+0x62
usertrap(ffff8000344d2410) at usertrap+0x129
recall_trap() at recall_trap+0x8
end of kernel
end trace frame: 0xc0001baab0, count: -9
Question regarding the above chunk.
Does the '1' in the uvmfault_lookup mean 1/TRUE was passed, so it did a
write lock (vm_map_lock_ln)? The code in uvm_fault_check() passes FALSE
to uvmfault_lookup and has a comment "locked: maps(read)", but it looks
like the write lock was grabbed?
