lkml.org 
[lkml]   [2015]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [EDT] [PATCH 1/1] Fix: hw watchpoint continually triggers callback
On Wed, May 13, 2015 at 06:14:30AM +0100, Vaneet Narang wrote:
> EP-2DAD0AFA905A4ACB804C4F82A001242F

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

> >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.

> > - 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).

Will


\
 
 \ /
  Last update: 2015-05-13 18:21    [W:0.072 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site