patchThe GNU Hurd - Patches: patch #6833, rpctrace: handle...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

patch #6833: rpctrace: handle mach_port_insert_right()

Submitter:  Zheng Da <zhengda>
Submitted:  Wed 20 May 2009 12:57:51 AM UTC
   
 
Category:  other Hurd Priority:  5 - Normal
Status:  Works For Me Privacy:  Public
Assigned to:  None Open/Closed:  Open
Planned Release:  None
Wiki-like text discussion box: 


Wed 20 May 2009 12:57:51 AM UTC, original submission:  

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

Zheng Da <zhengda>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #18168:  rpctrace.diff added by zhengda (9KiB - text/x-diff)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by zhengda (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-05-20 zhengda Attached File- Added rpctrace.diff, #18168

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code