Race condition between memory_object_terminate and RPCs

[Sergio Lopez]

Hello,

When a memory object is being terminated (because a change in its
"can_persist" attribute or being cleaned from cache), GNU Mach calls
memory_object_terminate. This simpleroutine, sends Mach's receive
right on memory object control port to the external memory manager. In
Hurd, a translator implementing libpager will process this message and
deallocate the control (and name) port by calling mach_port_destroy.

If a RPC is issued when the receive right has already been transfered
to the external memory manager and before this one deallocates the
port, the thread calling for that RPC will get stuck forever waiting
for a reply that will never come.

Although it should be possible to keep track of threads calling for a
RPC on a memory object, trying to cancel them if a m_o_terminate
message is received, I think it would be easier to early deallocate the
control port in the kernel, instead of transfering it to the memory
manager, since we don't actually make use of this feature.

In libpager, there's some code that tries to make use of these rights to
prevent the deallocation of the memory object until m_o_data_request
and m_o_data_return requests are processed, but in the first case it
doesn't make sense since m_o_data_error (the message we want to send
before object deallocation) will never arrive to the kernel (and if it
would, it would return KERN_INVALID_ARGUMENT since the memory object no
longer exists), and in the second one we just need to write the page to
the backing store, so there's no point in depending on the memory
object.

tl;dr: I suggest to change m_o_terminate simpleroutine, so it won't
transfer memory object control port receive right to the external memory
manager, deallocating it in the kernel instead.