Re: [3/3] Userspace probes prototype-take2

[Prasanna S Panchamukhi <prasanna at in dot ibm dot com>]

Yanmin,

On Mon, Feb 20, 2006 at 11:32:31AM +0800, Zhang, Yanmin wrote:
> >>-----Original Message-----
> >>From: Zhang, Yanmin
> >>Sent: 2006å2æ20æ 11:16
> >>To: Zhang, Yanmin; prasanna@in.ibm.com; systemtap@sources.redhat.com
> >>Subject: RE: [3/3] Userspace probes prototype-take2
> >>
> >>I lost an important comment. The patch is not aware of signal processing. After kernel prepares the single-step-inst on the stack, if
> >>a signal is delivered to the thread, kernel will save some states into stack and switch to signal handler function, so single-step-inst
> >>on the stack might be erased.
> >>
> >>>>-----Original Message-----
> >>>>From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org] On Behalf Of Zhang, Yanmin
> >>>>Sent: 2006å2æ17æ 17:20
> >>>>To: prasanna@in.ibm.com; systemtap@sources.redhat.com
> >>>>Subject: RE: [3/3] Userspace probes prototype-take2
> >>>>
> >>>>2 main issues:
> >>>>1) task switch caused by external interrupt when single-step;
> [YM] I think we could resolve this problem. Kernel probe has some differences from uprobe. One of them is that we couldn't estimate if kernel probe happens in process context, or interrupt context, while uprobe always happens in process context (user space). So from some points of view, uprobe could be simplified from kernel probe.
> a) Don't use kcb (kprobe_ctlblk) if uprobe is triggered. Create new functions, kprobe__handler_user, kprobe_fault_handler_user and other handlers. In the new functions, instead of kcb, we could use uprobe_page being allocated dynamically
.
Yes, I am trying to seperate out kprobes_handlers and uprobe_handlers
since user space probe handlers can preempt and might sleep. also given
that we might preempt, we cannot reuse the kprobe_handlers() that use rcu.
My next take will address this issues.

> Considering signal action handler (possible uprobe nested), a thread might have a list of uprobe_page.

Yes, reentrancy in this situation also need to be handled.

> b) Delete current_uprobe;

> 
> 
> 
> >>>>2) multi-thread:
> [YM] We could resolve this problem.
> a) Don't call replace_orignal_insn in function uprobe_single_step. It might cause a race condition.
> b) Delete copy_insn_on_new_page;
> c) Merge copy_insn_onstack and copy_insn_onexpstack. The single-step-insn address could be esp-sizeof(long long)-MAX_INSN_SIZE*sizeof(kprobe_opcode_t). 
This can be done.
> d) If the stack couldn't be expanded, just kill the thread. It's reasonable because the stack is used up.

We need to take a closer look at this issue

> 
> 
> >>>>
> >>>>See below inline comments.
> >>>>
> >>>>Yanmin
> >>>>
> >>>>>>-----Original Message-----
> >>>>>>From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org] On Behalf Of Prasanna S Panchamukhi
> >>>>>>Sent: 2006å2æ8æ 22:14
> >>>>>>To: systemtap@sources.redhat.com
> >>>>>>Subject: Re: [3/3] Userspace probes prototype-take2
> >>>>>>
> >>>>>>
> >>>>>>This patch handles the executing the registered callback
> >>>>>>functions when probes is hit.

-- 
Prasanna S Panchamukhi
Linux Technology Center
India Software Labs, IBM Bangalore
Email: prasanna@in.ibm.com
Ph: 91-80-51776329