netmap: Fix error handling in nm_os_extmem_create()

[markj]

Summary

We bump the object reference count prior to mapping it into the kernel
map, at which point the vm_map_entry owns the reference. Then, if
vm_map_wire() fails, vm_map_remove() will release the reference, so we
should avoid decrementing it in the error path.

Reported by: Ilja van Sprundel <[e-mail]>

[vmaffione]

Disclaimer: I am not familiar with the memory management subsystem.
From my understanding, vm_object_reference(obj) is called to account for the reference that we add by calling vm_map_find on the kernel map, since the comment on the latter function explicitly requires the caller to increment the object reference counter.
But I could not find evidence that vm_map_remove will actually remove the reference above.. is that the case? I tried to look in the code, but I could not find the spot nor comments or documentation about that. Also, I would think that vm_map_remove (which undoes what vmap_map_find does, I guess) does not drop the object reference since its counterpart also does not do it.

[markj]

In D53066#1213092, @vmaffione wrote:

Disclaimer: I am not familiar with the memory management subsystem.
From my understanding, vm_object_reference(obj) is called to account for the reference that we add by calling vm_map_find on the kernel map, since the comment on the latter function explicitly requires the caller to increment the object reference counter.
But I could not find evidence that vm_map_remove will actually remove the reference above.. is that the case? I tried to look in the code, but I could not find the spot nor comments or documentation about that. Also, I would think that vm_map_remove (which undoes what vmap_map_find does, I guess) does not drop the object reference since its counterpart also does not do it.

It's a bit indirect: the very end of vm_map_entry_delete() adds the entry (which still points to an object) to a per-thread queue. Then, when vm_map_remove() unlocks the map, it implicitly calls vm_map_process_deferred(), which frees the queued map entries after the map lock has been released. As a part of that, we drop the VM object reference.

[vmaffione]

Thanks for the explanation!
Btw, nm_os_extmem_delete calls only vm_map_remove, which confirms that this function must indeed drop the reference.