Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!sei.cmu.edu!fs7.ece.cmu.edu!o.gp.cs.cmu.edu!SYRAH.NECTAR.CS.CMU.EDU!rds From: rds+@CS.CMU.EDU (Robert Sansom) Newsgroups: comp.os.mach Subject: Re: Do NetMsgServers really extend Mach IPC to network TRANSPARENTLY? Message-ID: <1991Jun12.220121.29467@cs.cmu.edu> Date: 12 Jun 91 22:01:21 GMT References: <11355@bunny.GTE.COM> Sender: netnews@cs.cmu.edu (USENET News Group Software) Organization: Carnegie Mellon University Lines: 73 In article , dpj@CS.CMU.EDU (Daniel Julin) writes: |> |> In article <11355@bunny.GTE.COM> cy01@gte.com (Che-Liang Yang) writes: |> |> > Example 1: |> > |> > Suppose we have two Mach machines A and B. |> > Task A (in Machine A) creates a port, PORT A, |> > and gives the ownership right to Task B in Machine B. |> > According to the implementation of MSD 2.6 NetMsgServer: |> > in Kernel A, Task A has receive right (to Port A) |> > where NetMsgServer A has ownership right; |> > in Kernel B, Task B has ownership right |> > where NetMsgServer B has receive right. |> > |> > Now suppose that Task B exits. |> > NetMsgServer A must transfer the ownership right back to Task A |> > while still retaining the send right. |> > According to the implementation, NetMsgServer A: |> > 1. first msg_send itself a message with the send right to Port A, |> > 2. port_deallocate Port A, (This will transfer the ownership right |> > to Task A transparently.) |> > 3. msg_receive the message with send right to Port A. |> > |> > The problem is that the new port name obtained for Port A at step 3 |> > is not the same as that in step 1 where the port record |> > for Port A in NetMsgServer A still uses the old name. |> > The consequence is that now no tasks on remote machines can |> > send messages to Port A (because NetMsgServer A will |> > relay the message to an invalid port.) |> > Further, if later Task A exits: |> > 1. the logical name for Port A (checked in by Task A) |> > will still hang in NetMsgServer A; |> > 2. none of remote tasks with send rights to Port A will get notified. |> > |> > I solved this problem by having NetMsgServer A |> > port_rename the new name to the old name. |> > Although this works for Mach 2.5 kernel, |> > this is not a safe solution because I assume that |> > the kernel will not immediately reuse the name assigned to a |> > port just deallocated. |> > |> > So, my question is: |> > Under Mach 2.5 kernel, is there any safe way for a task |> > to transfer ownership right to another task |> > (which already has receive right) without sending a message |> > while still maintaining send right with the same name? |> |> This looks like a plain bug in the netmsgserver implementation, not |> any particular design problem. The fact that this bug has never been |> reported until now shows how often ownership rights are actually used, |> and partly justifies their removal from the IPC model... (see my |> additional comments below on this matter) |> |> The correct fix is not to rename the port right, but simply to update |> the port record for the port in question to have the new name for the |> port. Presumably, this port record is already locked while this rights |> transfer operation is in progress, so there should not be any problems |> with such an update. |> OK, I admit that the original implementation took advantage of the fact that the port would never be renamed during this "retention of send rights" hack. I know that this used to work as I explicitly tested for it as part of my PhD these work. In retrospect, it is obvious that the code should have checked in case the port did get renamed and then it should have done as Dan says and updated the port record (and I guess rehashed it). -- Robert Sansom, School of Computer Science Carnegie Mellon University, Pittsburgh, PA 15213 INTERNET: sansom@cs.cmu.edu CSNET: sansom%cs.cmu.edu@relay.cs.net BITNET: sansom%cs.cmu.edu@cmuccvma UUCP: ...!seismo!cs.cmu.edu!sansom