Preemption-safe kprobe-booster(Re: [PATCH]kprobe booster for IA64)

[Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>]

Hi, Anil

Masami Hiramatsu wrote:
> Hi, Anil
> 
> Keshavamurthy Anil S wrote:
>> pre_preempt_count will always be one here, since 
>> notify_die()->atomic_notifier_call_chain()->read_rcu_lock()->preeempt_disable(). 
>> So currently you might be preparing for boosting even for 
>> preemptable code path. Can you verify this.
> 
> Thank you for the advice!
> I hadn't realized it. Now, I verified it and had some ideas.
> The problem comes from reusing the insn buffer, because
> there might be some processes sleeping on the buffer.
> So, I think we can avoid this problem as below:
> First, we disable a kprobe (remove the break). Next,
> wait until all preempted processes are waken up. And Last,
> we release its insn buffer to reuse. Then, it will be safe.
> Because there is no process slept on the buffer.
> 
> For this purpose, I'd like to use stop_machine_run().

I and Oshima-san found that stop_machine_run() was not enough
to ensure safety. Instead of that, we focused on synchronize_sched().
As far as we know, this function waits until all processes
are expired. And any preempted processes can't be expired, only
the processes who are scheduled by itself are expired.
This means these processes already left from kprobe's slots.
So, after that, we can release/reuse these slots safely.

> However we can't execute it each releasing time because
> it is very costly.

synchronize_sched() is also costly.

> I think we can resolve it by using garbage collector.
> 
> I describe my idea below:
> The kprobe frees its insn slot(buffer) after disable it.
> Thus, when an insn slot is freed, it will be just marked as
> a garbage. And when get_insn_slot() can't find any free slot,
> it will call the garbage collector to try to refill free slots.

And the garbage collector uses synchronize_sched() to ensure safety.

> What do you think about this idea?
> 
> Best regards,
> 

Thanks,

-- 
Masami HIRAMATSU
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com