[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
- Re: mach_host_self() doesn't acquire new port name?!, (continued)
- Re: mach_host_self() doesn't acquire new port name?!, Thomas Bushnell, BSG, 2001/05/07
- Re: mach_host_self() doesn't acquire new port name?!, Marcus Brinkmann, 2001/05/08
- Re: mach_host_self() doesn't acquire new port name?!, Thomas Bushnell, BSG, 2001/05/08
- Re: mach_host_self() doesn't acquire new port name?!, Marcus Brinkmann, 2001/05/08
- Re: mach_host_self() doesn't acquire new port name?!, Marcus Brinkmann, 2001/05/08
- Re: mach_host_self() doesn't acquire new port name?!, Thomas Bushnell, BSG, 2001/05/08
- Re: mach_host_self() doesn't acquire new port name?!, Marcus Brinkmann, 2001/05/08
- Re: mach_host_self() doesn't acquire new port name?!, Thomas Bushnell, BSG, 2001/05/08
- Re: mach_host_self() doesn't acquire new port name?!,
Marcus Brinkmann <=