Looking at src changes this is probably expected, Nov 20 snapshot is still
affected.
login: uvm_fault(0xffffffff81cbc100, 0xffff800000b6e000, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at uvm_unmap_remove+0x212: movq 0x100(%r13),%r8
ddb{7}> set $lines = 0
ddb{7}> show panic
kernel page fault
uvm_fault(0xffffffff81cbc100, 0xffff800000b6e000, 0, 1) -> e
uvm_unmap_remove(f3660549fcbefe8b,ffffff03996f0b60,ffff800000b6df00,ffffff03996f0b50,ffff800022286480,0)
at uvm_unmap_remove+0x212
end trace frame: 0xffff8000222a50c0, count: 0
ddb{7}> trace
uvm_unmap_remove(f3660549fcbefe8b,ffffff03996f0b60,ffff800000b6df00,ffffff03996f0b50,ffff800022286480,0)
at uvm_unmap_remove+0x212
uvm_map_deallocate(c213623cf2be5b6) at uvm_map_deallocate+0x5e
vm_teardown(ffffff03996f0990) at vm_teardown+0xf0
vm_run(f3660549fca69a0f) at vm_run+0x226
VOP_IOCTL(703dbe68b198b2f2,ffffff03d3ba3c30,a50318ed4b52f246,ffff800022280338,ffffff043f7ca4e0,3)
at VOP_IOCTL+0x5a
vn_ioctl(51b27f479be0b418,ffffff03c287f178,ffff800022280338,20) at
vn_ioctl+0x6b
sys_ioctl(f1ce120ec2c9a54e,360,ffff800022280338) at sys_ioctl+0x3ec
syscall(33dbf1b60169518) at syscall+0x32a
Xsyscall(0,36,0,36,118700b52d0,11870035000) at Xsyscall+0x128
end of kernel
end trace frame: 0x11a7a41b340, count: -9
On Sun, Nov 11, 2018 at 9:56 AM Greg Steuck <[email protected]> wrote:
> Hi Mike,
>
> > Known issue. And the parameters in the list aren't right (there needs to
> be
> > something added to clang/llvm to support reading the params properly).
>
> This is happening often enough to create toil for running syzkaller with
> VMM. Is there a workaround that you know of? As things stand I end up
> monitoring this machine and rebooting on crashes. While I can automate this
> with some work, it feels deeply unsatisfying.
>
> Thanks
> Greg
>
