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().