Re: Crash in vm_terminate > vm_teardown > uvm_map_deallocate > uvm_unmap_remove

2018-10-02 Thread Mike Larkin
On Tue, Oct 02, 2018 at 08:21:39PM -0700, Greg Steuck wrote: > > Oh, if this is the issue then it's not "spinning". > > This is a different issue. This is a host crash rather than VMs getting > lost. > I'll give an update when I catch the spin. In the meantime, did the logs > describe the GCP

Re: Crash in vm_terminate > vm_teardown > uvm_map_deallocate > uvm_unmap_remove

2018-10-02 Thread Greg Steuck
> Oh, if this is the issue then it's not "spinning". This is a different issue. This is a host crash rather than VMs getting lost. I'll give an update when I catch the spin. In the meantime, did the logs describe the GCP environment in sufficient detail? > And this bug is a known issue, I just

Re: Crash in vm_terminate > vm_teardown > uvm_map_deallocate > uvm_unmap_remove

2018-10-02 Thread Mike Larkin
On Tue, Oct 02, 2018 at 07:35:29PM -0700, Greg Steuck wrote: > We got "lucky" in a different way after enabling VMM_DEBUG. I captured some > details of a > crash. The fault address seems to be vm_map(=0x80b44200) + 0x100. > > The kernel is built with this config: > ci-openbsd$ cat

Crash in vm_terminate > vm_teardown > uvm_map_deallocate > uvm_unmap_remove

2018-10-02 Thread Greg Steuck
We got "lucky" in a different way after enabling VMM_DEBUG. I captured some details of a crash. The fault address seems to be vm_map(=0x80b44200) + 0x100. The kernel is built with this config: ci-openbsd$ cat /syzkaller/src/sys/arch/amd64/conf/VMM_DEBUG include