[Bug uprobes/6850] New: uretprobe_instances mis-inherited

["jkenisto at us dot ibm dot com" <sourceware-bugzilla at sourceware dot org>]

If a probed process forks while running one or more uretprobed functions,
and the child attempts to return from such a function, the child will
hang.  The child incurs repeated SIGSEGVs and eats a lot of CPU, but
dies only if you kill -9 it.

This occurs because the child inherits the parent's stack, including any
return addresses that have been hijacked and replaced with the address
of the uretprobe trampoline.  So the function return vectors to the
trampoline, which doesn't exist in the child.  (The SSOL vma isn't
inherited, and neither is the utrace_engine.)

You can see this bug on i386 by probing all the entries in /bin/bash's PLT (*@plt).

A fix that works for i386 (and presumably x86_64 -- I haven't tested
it there) is to remember (in the uretprobe_instance) where in the
stack we hijacked the return address, then restore the original return
address(es) in the child in uprobe_report_clone().

Unfortunately, that fix probably won't work for architectures like
powerpc, where the location of the return address on the stack (if
it's ever saved to the stack) is hard to predict.

A more general solution is to adjust fork handling in
uprobe_report_clone() as follows:
- If the parent task's uretprobe_instances list is empty, we're done.
- Call uprobe_mk_process() to create a uprobe_process and uprobe_task
for the child.  Leave uproc->uretprobe_trampoline_addr NULL; this
will be initialized along with the SSOL vma on the fly if/when the child
returns from a uretprobed function.  (Gotta verify that the child's
SSOL vma shows up at the same address.)
- Clone the parent's uretprobe_instances in the child, ref-counting
the child's uprobe_process for each.
- Add the child to the uproc_table.
- Pay careful attention to module and uprobe_process ref-counts.
Don't call lock_uproc_table() while holding a uprobe_process's rwsem.

-- 
           Summary: uretprobe_instances mis-inherited
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P1
         Component: uprobes
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: jkenisto at us dot ibm dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=6850

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.