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

[Marcus Brinkmann]

On Tue, May 08, 2001 at 11:48:44AM -0700, Thomas Bushnell, BSG wrote:
> Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> 
> > BTW, what about the count of user refs in the port name entry of the tasks
> > port name space?  We don't set any policy here, so I suspect that here a
> > task will simply get a failure on overrunning the user references.
> 
> There are two ref counts to keep track of; I'll call these local and
> global references.  A local reference is the number of user references
> task T has to the right.  The task itself holds a single global
> reference, which is the total number of tasks holding send rights for
> the port.

Doh!  I was taking ip_srights as the sum of all urefs.  Now, with this in
mind, the pieces snap into place.

> > Also, I can't find any handling of underruns in dealloc (mod_refs has, see
> > ipc_right_delta).  
> 
> What are you talking about here?  Where do you expect to see handling
> of underruns but you don't?  In ipc_right.c:ipc_right_copyout, the
> kernel is holding a (global) reference to the port; it is that
> reference which is deallocated after the user-reference count is
> incremented.  It can't underflow; it's got a reference that it's
> deallocating. 

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.

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.

The kernel could prevent this only by not lowering the number of urefs below
1 for such port types (a new flag would be needed for that, I think).  This
is equivalent of leaking a user reference, but this is equivalent to
running mach_host_self() without deallocating it. And we said that this is ok.

I agree with you that ip_srights is not to be worried about.  The day we can
run 2^32 tasks in parallel (or even something remotely close) is far away. 
A quick calculation shows that this would require tens of thousands GB RAM
(and a processor which can handle so much work ;)

> I don't know whether you noted it, but mach_host_self does not check
> to see whether ipc_port_make_send will succeed.

I didn't notice it, so it is good you told me.

Thanks for the thorough explanation,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de