🚀 go-pugleaf

In article <1991Jun12.220121.29467@cs.cmu.edu>, rds+@CS.CMU.EDU (Robert Sansom) writes:
|> In article <DPJ.91Jun12134524@NATASHA.MACH.CS.CMU.EDU>, 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
_________________________________________________________________________