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.
