On Tue, May 08, 2001 at 11:48:44AM -0700, Thomas Bushnell, BSG wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd