[PATCH RFC 2/6] arm64: Kprobes with single stepping support

[masami.hiramatsu.pt@hitachi.com (Masami Hiramatsu)]

(2013/11/11 16:54), Masami Hiramatsu wrote:
>>>> In fact, how do you avoid a race with hardware breakpoints? E.g., somebody
>>>> places a hardware breakpoint on an instruction in the kernel for which
>>>> kprobes has patched in a brk. We take the hardware breakpoint, disable the
>>>> breakpoint and set up a single step before returning to the brk. The brk
>>>> then traps, but we must take care not to disable single-step and/or unmask
>>>> debug exceptions, because that will cause the hardware breakpoint code to
>>>> re-arm its breakpoint before we've stepped off the brk instruction.
>>>
>>> Hmm, frankly to say, this kind of race issue is not seriously discussed
>>> on x86 too, since kgdb is still a special tool (not used on the production
>>> system).
>>> I think under such situation kgdb operator must have full control of the
>>> system, and he can (and has to) avoid such kind of race.
>> Masami,
>>
>> Hmm I think in same lines, but not sure if we expect kprobes to be
>> able to work fool-proof along with kgdb or hw breakpoints ?
> 
> For hw breakpoint, yes, we finally get check each other to safely
> use it even if one rejects the other one at some points(address).
> Since the hw breakpoint is already open for normal user via perf,
> we should do it. But the policy still needs to be discussed.

OK, I've ensured that the hw_breakpoint (from perf) can work
with kprobes (from ftrace) at the same address on x86.
So if arm64 already support hw_breakpoint on perf, kprobes should
work with it.

Thank you,

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt at hitachi.com