Re: [PATH 1/3] User space probes-take3-RFC

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

Bibo,

Thanks for writting excellent test cases.
Please find my comments inline below.

On Wed, Mar 08, 2006 at 05:27:50PM +0800, bibo,mao wrote:
> prasanna,
> I composed one example to test uprobe, it is in the attachment. And I 
> compile uprobe.c with the command:
> 	gcc --static -g -o uprobe uprobe.c
> 	readelf --sections uprobe
> And in kprobe-ex.c, some environment variant need modification.
> 	#define PROBE_FILENAME  "/root/test/uprobe"
> 	/* program text segment start address */
> 	#define TEXT_START      0x8048150
> 	/* program text segment offset */	
> 	#define TEXT_OFFSET     0x150
> 	/* probed instruction position */
> 	#define PROBE_POS       0x8048304
> And there are some problems about current uprobe patch
> 1) it influences some operations about probed inode. Because there is 
> hook function like readpage(s), when kprobe-ex.ko module is inserted, if 
>  some operation like "cp uprobe uprobe1" is executed, file uprobe1 will 
> include inserted "int3" instruction.


Looks like this problem was addressed in the original dprobes, We are
investigating this issue.

> 
> 2) if probed instruction cause stack vma page fault, there will be some 
> debug information like this:
> 
> void test_stack(){
>    int i;
>    int p[STACK_LIMIT];
> 
> /* set user probepoint here, and default there will
>  * be do_page_fault handler to expand stack
>  */
> 	p[0]=0;	
> 	i=0;
> 	i++;
> }
> passed: prehandler executed
> BUG: sleeping function called from invalid context at mm/rmap.c:84
> in_atomic():0, irqs_disabled():1
>  <c014c72f> anon_vma_prepare+0x1b/0xbc   <c011b885> 
> release_console_sem+0x1a1/0x1a9
>  <c0148e1f> expand_stack+0x15/0xf1   <c02bb83c> do_page_fault+0x282/0x697
>  <c02bb5ba> do_page_fault+0x0/0x697   <c0103423> error_code+0x4f/0x54
>  <c01adbf6> __copy_to_user_ll+0xcf/0xda   <c02ba977> 
> uprobe_exceptions_notify+0x166/0x609
>  <c02bbc66> notifier_call_chain+0x15/0x25   <c02ba646> do_int3+0x3c/0x7b
>  <c02ba332> int3+0x1e/0x24
> passed: post handler executed


There are two solutions to the above problem ie page fault while *single
stepping*.

1. Reset the probe to the probed address and allow it to recurse
   'n' times. Disarm it on (n+1)th fault and release locks.

2. Disarm the probe permanently and inform the user right away using
   some flags and release locks.

> 
> 3)if probed instruction cause heap vma page fault, the applicatin will 
> hangup.
> void test_heap(){
>    char *pchar;
> 	
> 	pchar = (char*) malloc(HEAP_LIMIT);
> 	pchar += (HEAP_LIMIT - 1);
> 	*pchar = 'c';  //set probe point here
> }
> passed: prehandler executed
> passed: page fault executed
> passed: prehandler executed
> BUG: scheduling while atomic: uprobe/0x00000002/7199
>  <c02b7dbf> schedule+0x43/0x73f   <c011be4f> vprintk+0x2be/0x2f6
>  <c02b8e3f> __wait_on_bit_lock+0x4b/0x52   <c013b011> __lock_page+0x69/0x70
>  <c02b8673> io_schedule+0x26/0x30   <c013b094> sync_page+0x0/0x3b
>  <c013b0cc> sync_page+0x38/0x3b   <c02b8e1e> __wait_on_bit_lock+0x2a/0x52
>  <c013b011> __lock_page+0x69/0x70   <c012bdf1> wake_bit_function+0x0/0x3c
>  <c02bab7c> uprobe_exceptions_notify+0x36b/0x609   <c02bbc66> 
> notifier_call_chain+0x15/0x25
>  <c02ba646> do_int3+0x3c/0x7b   <c02ba332> int3+0x1e/0x24
>  <c02b007b> __xfrm_policy_check+0x2a6/0x657
> passed: page fault executed
> BUG: spinlock wrong owner on CPU#1, syslog-ng/3683
>  lock: c0362664, .magic: dead4ead, .owner: uprobe/7199, .owner_cpu: 0
>  <c01ae774> _raw_spin_unlock+0x43/0x6c   <c02ba14a> 
> _spin_unlock_irqrestore+0x8/0xc
>  <c02badad> uprobe_exceptions_notify+0x59c/0x609   <c02bbc66> 
> notifier_call_chain+0x15/0x25
>  <c02bb5ba> do_page_fault+0x0/0x697   <c02bb775> do_page_fault+0x1bb/0x697
>  <c015f786> sys_stat64+0x1e/0x23   <c01344ae> do_gettimeofday+0x31/0xda
>  <c02bb5ba> do_page_fault+0x0/0x697   <c0103423> error_code+0x4f/0x54
> 


Same as above.

> 4) if probed instruction is int3, system will crash.
> void test_trap3()
> {
> /* set probepoint at here */	
> 	asm volatile (".byte 0xcc");
> }
> system will crash.

This scenerio is similar to the case where in a debugger (like gdb)
puts a breakpoint and then the user also want to insert the probe
at the same address.

As was discussed a while back, we will not allow a probe to be inserted
at an address that already has a breakpoint. This ofcourse will need
assistance from other user-space debuggers.

As of now we will not allow the probes to be inserted on an existing
breakpoint.

I will send out a patch to fix the above problems.

Thanks
Prasanna

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