Re: miscfs/specfs/spec_vnops.c panic (triggered by filemon(4))

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

   Date: Tue, 5 Jan 2016 09:13:01 +0800 (PHT)
   From: Paul Goyette <paul%whooppee.com@localhost>

   Note: from the kernel map, 0xffffffff805e3120 is the address of 
   vmspace0, as would be expected from the above initialization code.  The 
   map doesn't have anything that corresponds to 0xffffffff805dea80 - the 
   closest items are

                    0xffffffff805ddd70                kmembase
     .bss           0xffffffff805deba0       0x70 uvm_loan.o

The address you see in kernel_map, 0xffffffff805dea80, is doubtless
that of kernel_map_store, defined in uvm/uvm_km.c.  Its function
appears to be for uvm_km(9) allocations.  But it shares a pmap with
vmspace0's vm_map, namely the kernel pmap -- that is, it refers to the
same assignment of physical pages to virtual addresses.

I'm not clear on what purpose vmspace0's vm_map serves.  It may be
that nothing uses it, in which case maybe kernel_map should just be
vmspace0's vm_map and there shouldn't be a separate kernel_map_store.
But that's neither here nor there.

It's clear that, with the status quo, in

>>>     if (&uio->uio_vmspace->vm_map != kernel_map &&
>>>         uio->uio_vmspace != curproc->p_vmspace)

the first condition will never be true unless someone assigns
kernel_map, which I don't expect to ever happen -- kernel_map =
&kernel_map_store is not the vm_map of any vmspace.

So I think DIAGNOSTIC condition is wrong.  I think the right condition
is probably uio->uio_vmspace == vmspace_kernel().

While you're here, please change #if DIAGNOSTIC into KASSERT or
KASSERTMSG.