Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!hp4nl!utrcu1!infnews!gansevle From: gansevle@cs.utwente.nl (Fred Gansevles) Newsgroups: comp.os.mach Subject: Re: Do NetMsgServers really extend Mach IPC to network TRANSPARENTLY? Message-ID: <1991Jun18.121951@cs.utwente.nl> Date: 18 Jun 91 10:19:51 GMT References: <11355@bunny.GTE.COM> <1991Jun12.220121.29467@cs.cmu.edu> Sender: gansevle@cs (Fred Gansevles) Organization: University of Twente, Dept. of Computer Science Lines: 85 Originator: gansevle@utis12 In article <1991Jun12.220121.29467@cs.cmu.edu>, rds+@CS.CMU.EDU (Robert Sansom) writes: |> 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 -- _________________________________________________________________________ Fred Gansevles e-mail: gansevle@cs.utwente.nl Phone: +31 53 89 3744 University Twente Dept of CS Box 217 7500 AE Enschede Netherlands _________________________________________________________________________