[patch #6833] rpctrace: handle mach_port_insert_right()

[Zheng Da]

URL:
  <http://savannah.gnu.org/patch/?6833>

                 Summary: rpctrace: handle mach_port_insert_right()
                 Project: The GNU Hurd
            Submitted by: zhengda
            Submitted on: Wed 20 May 2009 12:57:51 AM GMT
                Category: other Hurd
                Priority: 5 - Normal
                  Status: Works For Me
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
Wiki-like text discussion box: 

    _______________________________________________________

Details:

This patch is mainly to make rpctrace handle mach_port_insert_right()
properly. 

With patch #6830 (https://savannah.gnu.org/patch/?6830), rpctrace can trace
all tasks and threads, but still cannot trace fork(). The main problem is that
it cannot handle the case below:
 
mach_port_allocate_name (newtask, MACH_PORT_RIGHT_RECEIVE, portnames[i]);
mach_port_extract_right (newtask, portnames[i], MACH_MSG_TYPE_MAKE_SEND,
&port, &poly);
mach_port_insert_right (newtask, portnames[i], port,
MACH_MSG_TYPE_MOVE_SEND)

The original rpctrace doesn't know a port is created when
mach_port_allocate_name() is called. when mach_port_extract_right() is called,
'port' is translated and is the send right to the wrapper port in rpctrace.
The original rpctrace doesn't translate the port passed by
mach_port_insert_right().
 
Therefore, when the sequence of RPCs as above is called, the send right to
the wrapper in rpctrace is moved to the target 'newtask' and the operation
fails with the error "name exists".

To fix this problem, I start with tracing the receive right created by
mach_port_allocate() and mach_port_allocate_name(). 

The strategy for handling the send right in mach_port_insert_right() is:
if the send right is moved to the task who has the receive right, translate
it into a send right to the same port as the receive right if necessary.
Otherwise, translate it into a send right to the wrapper in rpctrace if
necessary.

We take the case above for example. A send right is moved from the caller's
task to the target 'newtask', who has the receive right, translate the send
right. 

In the case below:
mach_port_allocate (mach_task_self (), &port);
mach_port_insert_right (mach_port_self (), port, port,
MACH_MSG_TYPE_MAKE_SEND);
The send right doesn't need to be translated.

The old strategy of moving the receive right should work for
mach_port_insert_right(). I don't know how the send once right is usually used
so I haven't handled the send once right in mach_port_insert_right().

In principle, the strategy of moving send right can be applied to other
cases, but it's very difficult to do it in reality simply because we don't
always know whether the recipient of the message has the receive right,
especially for the reply. For example (it might be a very bad example):
  err = mach_port_allocate (mach_task_self (), MACH_PORT_RIGHT_RECEIVE,
&receive_right);
  err = mach_port_extract_right (mach_task_self (), receive_right,
MACH_MSG_TYPE_MAKE_SEND, &receive_right, &poly);

the caller of mach_port_extract_right should get the send right to the same
port as the receive right. However, if the code is traced by rpctrace, the
caller gets the send right to the wrapper in rpcatrace. I don't know how to
handle this case properly.

Another problem for this strategy is that we have to keep tracing the receive
right and know which task has it. Again, mach_port_extract_right() is a very
difficult case to handle.

Some other problems are left in the patch. For example,
how to destroy the wrapper?

Could anyone give me some suggestions?

Thank you,
Zheng Da



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Wed 20 May 2009 12:57:51 AM GMT  Name: rpctrace.diff  Size: 9kB   By:
zhengda

<http://savannah.gnu.org/patch/download.php?file_id=18168>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/patch/?6833>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/