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

[Marcus Brinkmann]

On Mon, May 07, 2001 at 11:19:08PM -0700, Thomas Bushnell, BSG wrote:
> Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> 
> > Overflowing the ip_srights reference count in the port structure.
> 
> Right.  So since mach_host_self sets OVERFLOW, the result of maxing
> out the user refs is harmless.  (If it didn't set it, then
> mach_host_self might sometimes get an error; that would be a problem,
> but it does set it, so it isn't.)

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.

Also, I can't find any handling of underruns in dealloc (mod_refs has, see
ipc_right_delta).  This would mean that it is a mistake to deallocate send
rights (I think it could trigger first a wrong no-senders message, and then
an assertion srights > 0. Imagine task A pushing the port srights count to
the maximum, task B getting a user reference, task A deallocating all
srights.  This will lower the number of srights counted to 0, producing a
no senders message.  If now B tries to deallocates his reference, the
assertion will fail.

Of course this is hypothetical, but only as hypothetical as the assumption
that the overrun feature is used in the first place.  As port rights are
deallocated implicitely at task termination, there is no way to avoid this
underrun problem when the limits are hit.

Thanks,
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