Re: djprobes status

[Satoshi Oshima <soshima at redhat dot com>]

Hi Ingo,

I have been thinking how I implement djprobes on your advice.
And I have found some difficulties on some plans.

Before my explanation, I would like to introduce a couple of
rules that djprobes must follow.

(1) On out of line execution of probed code, registers and 
    stack must be the same state that is probed, 
    because probed code may touch the stack or registers. 
    This include flag registers, so we cannot prevent 
    interruption at least during the out of line execution.
    (Or we have to add other restrictions on djprobes users
     such as "don't probe the code that touch stack")

(2) Probes may nest, which means that another probe may
    be hit during interruption or exception handling.


And I explain what prevent me.

Plan A: push $target_IP; ret 
        (or push flag;push $target_IP;iret) method

Djprobes must have multiple probe points and support
multi processor environment. They have to follow rule(2).
So $target_IP must be like $target_IP[$cpuid][$depth_of_nest],
and preempted processes may move to another processor.
It is hard to fixup after out of line execution started.

Plan B: inserting pushfd+cli+jmp+popfd

If we mask interruptions on probe, we have to unmask it
during out of line execution to follow rule(1). And we
have the same problem on plan A again.


Now we have 3 options left.

Plan C: fixup preempted address in the task_struct

Plan D: making safety check on preempted address 
        in the task_struct

Plan E: freeze_processes()/thow_processes()


I realize that Plan C&D is highly archtecture dependent
and Intel CPU's erratta may bring another problem. 
And someone pointed me out that current djprobes 
implementation is very hard to port to some other 
architectures.

So We would like to try Plan E first. The code will be
simpler and mainly architecture independent.

After that, we can try to introduce current djprobes
implementation if performance optimization is required.

Anyway, thank you for your advice and appreciate your
comment.

Satoshi


Masami Hiramatsu wrote:
> Hi Ingo,
> 
> Ingo Molnar wrote:
>> yes, my suggestion above was to occasionally do (for every 1000 buffers
>> or 10000 buffers) something like:
>>
>> 	freeze_processes();
>> 	list_for_each_entry(&list)
>> 		release_buffer(buffer);
>> 	thaw_processes();
>>
>> this way the trampoline code is the simplest possible (and the fastest
>> possible) as we dont have to add preempt_disable()/enable() to the
>> trampoline code. Am i missing some important complication?
> 
> No, you're right. I like this idea because of architecture-
> independence and simplicity.
> 
> I think this method can be applied to ensure the safety of
> kprobe-booster on preemptive kernel. Actually, the kprobe-booster
> implementation is very similar to the bottom half of the djprobe.
> It executes copied instruction directly and jumps back to the kernel
> code, instead of single-stepping.
> Thus, if some processes are preempted on the copied instruction,
> it cannot release the buffer which contains the copied instruction.
> Currently, the kprobe-booster is disabled on the preemptive kernel,
> but I'll make the patch to enable it by using these functions and try it!
> 
> Thanks a lot!
>