Re: mach_host_self() doesn't acquire new port name?!

[Thomas Bushnell, BSG]

Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:

> With my better understanding, I would say it this way: If I call
> mach_host_self() 2^16 and a couple times, and then call
> mach_port_deallocate on the port name returned by these calls 2^16
> times, then the urefs will drop to zero and the port name in the
> port name space will be destroyed by ipc_right_dealloc.  But the
> user might expect that he has a couple of send rights (user
> references) left.

Yes, that's true.  The user should know that incrementing his count
that far has curious results.  If you want to fix it, you might do so
by inserting a change to ipc_right_dealloc that preserves the "pegged"
value, and refuses to reduce urefs if we pegged it sometime in the
course of adding a uref.  

Note that this can only happen if ipc_right_copyout was called with
OVERFLOW set.  A brief scan of the code (I might have missed some),
shows that this happens only when handling kmsg's and in
ipc_port_copyout_send; the latter is used only for mach_host_self,
mach_task_self, and mach_thread_self.

Note the objects that kmsg's handle are all kernel objects, for which
references are not counted.  (Or rather, the counts for which don't
matter because nothing happens to the objects when the count
vanishes.) 

> Now, a host name port send_right is not something that is used in
> such a nested way, and any other scenario sounds extremely unlikely
> (like, 2^16 threads running host = mach_host_self (); foo(host);
> mach_port_deallocate (host) in parallel). But anyway, that would be
> the type of underflow I mean.

Ok, then the user should be sure not to deallocate them. :)