bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Marcus Brinkmann
Subject: Re: mach_host_self() doesn't acquire new port name?!
Date: Wed, 9 May 2001 01:48:14 +0200
User-agent: Mutt/1.3.15i

On Tue, May 08, 2001 at 04:18:31PM -0700, Thomas Bushnell, BSG wrote:
> 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.  

Right.  You'd need to lower the upper limit by one so that you can decide
between a full non-overflowing port and a port that has overflown. Or,
alternatively, have an extra bit somewhere.

> 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.

I don't think we should bother to change anything for those.  As you say:

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

Works for me.  Users can implement their own refcounting with a lock, a
counter and mach_port_destroy if they really need it.  Or cache the value.
Only if at some time servers in user space were allowed to specify overflow
to be true for a receive port, then I think it might make sense to fix the
underflow side, too.  But I have my doubts that this is a useful feature.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]