Re: [EDT] [PATCH 1/1] Fix: hw watchpoint continually triggers callback

[Vaneet Narang]

 EP-2DAD0AFA905A4ACB804C4F82A001242F
>
>Ok, I have to ask: what on Earth is this number and what does [EDT] mean?

This is auto generated from our editor. Kindly ignore its not relevant.
Please find reply inline.

>> >On Tue, May 12, 2015 at 02:12:54PM +0100, Vaneet Narang wrote:
>> >> On Tue, May 12, 2015 at 12:48:13PM +0100, Maninder Singh wrote:
>> >> This fix is given for kernel developers who wants to use perf interface by
>> >> registering callback using register_wide_hw_breakpoint API.  On every
>> >> callback trigger they have to unregister watchpoints otherwise callback
>> >> gets called in a loop and now issue is "when to register watch point back
>> >> ?". 
>> 
>> >If you want to solve this, I think we need a better way to expose software
>> >single-step/emulation to the overflow handler. If we try to do this in
>> >the hw_breakpoint code itself, we run into problems:
>> 
>> >  - What if another thread hits the same instruction whilst we are trying
>> >   to step it?
>> 
>> >  - What if there are two breakpoints or a breakpoint + watchpoint
>> >   triggered by the same instruction?
>> 
>> Thanks for you input. I am not sure, issues which you have mentioned with
>> this implementation will actually come.
>> To address the issues you have raised, I need to brief about kprobe.
>> Kprobe follows 3 steps for breakpoint (BP) handling.
>> 1. Decode BP instruction.
>> 2. Replace BP instruction with new instruction that will generate SWI.
>> 3. Execute instruction & move PC to next instruction.
>> Kprobe follows step 1 & step 2 on addition of BP and 3rd step is followed
>> when SWI gets triggered.
>> 
>> For this fix we have used step 1 & step 3, we have skipped step 2. As we
>> don't know the caller of watch point & also HW generates interrupt so step
>> 2 is not required. The only difference is since we don't know the caller
>> we can't decode instruction in advance. We have to follow step 1 and step
>> 3 when HWI gets triggered.  Since we are not replacing instruction from
>> memory and I assume kprobe implementation for execution of instruction in
>> interrupt context is tested and stable, so it shouldn't  produce any of
>> the above race condition issues.

>
>Ok, so my first point shouldn't be a problem if we're just emulating the
>instruction. However, I still think there are corner cases. For example,
>imagine hitting a breakpoint on a ldr pc, [&foo] instruction where we've
>also got a watchpoint on foo. Even with emulation, it's going to be
>difficult to ensure that watchpoint is safely delivered.
>
>As I say, I'd really rather have a kprobes-agnostic way of stepping an
>instruction and let the debugger decide whether it wants to use that or
>not.
>

2 breakpoints will not be any issue but watchpoint + breakpoint is interesting scenario with ldr pc, [&foo] instruction in place. 
How would ARM will behave in this case without kprobe ? I think It will keep on generating Watch point interrupt only.

With kprobe watchpoint interrupt gets triggered first and as soon as we execute ldr pc, [&foo] using kprobe
it will trigger Breakpoint interrupt.  
This can be taken care with special handling for such instruction where PC gets changed. Can you please suggest what should be correct behavior in this case ?
Is this scenario possible with any other instruction. ? I am not able to think other instructions. Is it possisble with push or pop ?

>> >  - What if the debugger didn't want to execute the instruction at all?
>> 
>> if debugger doesn't want to execute instruction then debugger should use
>> single step implementation without overflow handler. 
>
>But the debugger might want to use the overflow handler to regain control
>on the exception (like ptrace does for userspace).
>
I have tried same kernel module on x86, Linux 3.5. Behavior on x86 is to execute instruction.
I am not sure how ptrace works on x86, if instruction gets executed without any control from overflow handler.
Behavior on ARM should be same as x86. Since perf API interface is same on ARM as well as x86.

>Will

Regards,
Vaneet Narang