On Mon, Nov 29, 2021 at 10:50:32PM +0100, Martin Pieuchot wrote: > On 24/11/21(Wed) 11:16, Martin Pieuchot wrote: > > Diff below unlock the bottom part of the UVM fault handler. I'm > > interested in squashing the remaining bugs. Please test with your usual > > setup & report back. > > Thanks to all the testers, here's a new version that includes a bug fix.
Passed amd64 regress with two witness reports. I don't know whether they were there without the diff. witness: lock order reversal: 1st 0xfffffd87764d68c8 vmmaplk (&map->lock) 2nd 0xfffffd873a6516f8 inode (&ip->i_lock) lock order "&ip->i_lock"(rrwlock) -> "&map->lock"(rwlock) first seen at: #0 rw_enter_read+0x38 #1 uvmfault_lookup+0x92 #2 uvm_fault_check+0x32 #3 uvm_fault+0xfb #4 kpageflttrap+0x12b #5 kerntrap+0x91 #6 alltraps_kern_meltdown+0x7b #7 copyout+0x53 #8 ffs_read+0x1f6 #9 VOP_READ+0x41 #10 vn_rdwr+0xa1 #11 vmcmd_map_readvn+0xa6 #12 exec_process_vmcmds+0x84 #13 sys_execve+0x79f #14 start_init+0x29f #15 proc_trampoline+0x1c lock order "&map->lock"(rwlock) -> "&ip->i_lock"(rrwlock) first seen at: #0 rw_enter+0x65 #1 rrw_enter+0x56 #2 VOP_LOCK+0x5b #3 vn_lock+0xad #4 uvn_io+0x1e7 #5 uvm_pager_put+0xf7 #6 uvn_flush+0x260 #7 uvm_map_clean+0x21d #8 syscall+0x3a9 #9 Xsyscall+0x128 witness: lock order reversal: 1st 0xfffffd886a277768 vmmaplk (&map->lock) 2nd 0xffff800022c46360 nfsnode (&np->n_lock) lock order data w2 -> w1 missing lock order "&map->lock"(rwlock) -> "&np->n_lock"(rrwlock) first seen at: #0 rw_enter+0x65 #1 rrw_enter+0x56 #2 VOP_LOCK+0x5b #3 vn_lock+0xad #4 vn_rdwr+0x7f #5 vndstrategy+0x2e6 #6 physio+0x227 #7 spec_write+0x95 #8 VOP_WRITE+0x41 #9 vn_write+0xfc #10 dofilewritev+0x14d #11 sys_pwrite+0x5c #12 syscall+0x3a9 #13 Xsyscall+0x128 bluhm
