On 18 November 2013 12:25, Sandeepa Prabhu wrote:
>>> This is generic test module (samples/hw_breakpoint/data_breakpoint.ko)
>>> which places watchpoint for bothe read/write.
>>> Atleast watchpt should have triggered for Read right? I also tried
>>> with othe functions like do_fork, vfs_read etc b
>> This is generic test module (samples/hw_breakpoint/data_breakpoint.ko)
>> which places watchpoint for bothe read/write.
>> Atleast watchpt should have triggered for Read right? I also tried
>> with othe functions like do_fork, vfs_read etc but no hit.
>
> You'd need to place something for exec i
On 15 November 2013 22:07, Will Deacon wrote:
>> well, kprobes does not step from kernel address, but it prepares a
>> allocated memory(executable), copies the instruction and update the
>> single step address (ELR) to enable stepping while ERET.
>> So, don't we need NOP at next location after t
On Wed, Nov 13, 2013 at 03:55:42PM +, Sandeepa Prabhu wrote:
> On 13 November 2013 20:01, Will Deacon wrote:
> > On Wed, Nov 13, 2013 at 06:55:33AM +, Sandeepa Prabhu wrote:
> >> 1. Placing watchpoint ( attr.bp_type = HW_BREAKPOINT_W |
> >> HW_BREAKPOINT_R) upon vfs_symlink symbol, but se
On Tue, Nov 12, 2013 at 06:52:51AM +, Sandeepa Prabhu wrote:
> On 11 November 2013 16:51, Will Deacon wrote:
> > On Mon, Nov 11, 2013 at 05:35:37AM +, Sandeepa Prabhu wrote:
> >> On 8 November 2013 22:26, Will Deacon wrote:
> >> >> +#define MAX_INSN_SIZE 2
> >> >
> >> > W
(2013/11/13 1:59), Steven Rostedt wrote:
> On Tue, 12 Nov 2013 16:25:26 +0530
> Sandeepa Prabhu wrote:
>
>
>>>
>>> BTW, I'm currently trying a general housecleaning of __kprobes
>>> annotations. It may also have impact on your patch.
>>> https://lkml.org/lkml/2013/11/8/187
>> Hmm, we can help te
On 13 November 2013 20:01, Will Deacon wrote:
> On Wed, Nov 13, 2013 at 06:55:33AM +, Sandeepa Prabhu wrote:
>> >>> I'm unsure about arm64's debug feature behavior, what does happen when
>> >>> it performs a single-step on sw-breakpoint?
>> >>>
>> Sandeepa: I think you need to retry Masam
On Wed, Nov 13, 2013 at 06:55:33AM +, Sandeepa Prabhu wrote:
> >>> I'm unsure about arm64's debug feature behavior, what does happen when
> >>> it performs a single-step on sw-breakpoint?
> >>>
> Sandeepa: I think you need to retry Masami's test on the arm64 model,
> since
> I'm
On Wed, Nov 13, 2013 at 01:58:07PM +, Peter Zijlstra wrote:
> On Mon, Nov 11, 2013 at 10:58:12AM +, Will Deacon wrote:
> > Single-stepping on x86 is different to the step behaviour on arm64 afaik. On
> > ARM, we have to manually remove the breakpoint, perform a single-step, then
> > add the
(2013/11/13 15:55), Sandeepa Prabhu wrote:
I'm unsure about arm64's debug feature behavior, what does happen when
it performs a single-step on sw-breakpoint?
> Sandeepa: I think you need to retry Masami's test on the arm64 model,
> since
> I'm fairly sure it won't work a
On Mon, Nov 11, 2013 at 10:58:12AM +, Will Deacon wrote:
> Single-stepping on x86 is different to the step behaviour on arm64 afaik. On
> ARM, we have to manually remove the breakpoint, perform a single-step, then
> add the breakpoint again. If we re-enable debug exceptions in the kprobe
> hand
On 13 November 2013 12:25, Sandeepa Prabhu wrote:
I'm unsure about arm64's debug feature behavior, what does happen when
it performs a single-step on sw-breakpoint?
> Sandeepa: I think you need to retry Masami's test on the arm64 model,
> since
> I'm fairly sure it won'
On Tue, 12 Nov 2013 16:25:26 +0530
Sandeepa Prabhu wrote:
> >
> > BTW, I'm currently trying a general housecleaning of __kprobes
> > annotations. It may also have impact on your patch.
> > https://lkml.org/lkml/2013/11/8/187
> Hmm, we can help testing your patchset on arm64 platforms. Also have
(2013/11/12 19:55), Sandeepa Prabhu wrote:
> Thanks for steps, ARM64 ftrace patches are under review on arm mailing
> list, I can contact the (linaro) developer implementing ftrace on
> what's supported and then figure-out a way to test this concurrency of
> kprobes breakpoint and h
On 12 November 2013 15:47, Masami Hiramatsu
wrote:
> (2013/11/12 17:44), Sandeepa Prabhu wrote:
>> On 12 November 2013 12:57, Masami Hiramatsu
>> wrote:
>>> (2013/11/12 15:23), Sandeepa Prabhu wrote:
>>> OK, I've ensured that the hw_breakpoint (from perf) can work
>>> with kprobes (from f
(2013/11/12 17:44), Sandeepa Prabhu wrote:
> On 12 November 2013 12:57, Masami Hiramatsu
> wrote:
>> (2013/11/12 15:23), Sandeepa Prabhu wrote:
>> 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 alrea
On 12 November 2013 12:57, Masami Hiramatsu
wrote:
> (2013/11/12 15:23), Sandeepa Prabhu wrote:
> 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
>>
(2013/11/12 15:23), Sandeepa Prabhu wrote:
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.
>>>
>>> Single-stepping on x86 is differ
On 11 November 2013 16:51, Will Deacon wrote:
> On Mon, Nov 11, 2013 at 05:35:37AM +, Sandeepa Prabhu wrote:
>> On 8 November 2013 22:26, Will Deacon wrote:
>> >> diff --git a/arch/arm64/include/asm/kprobes.h
>> >> b/arch/arm64/include/asm/kprobes.h
>> >> new file mode 100644
>> >> index 000
>>> 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.
>>
>> Single-stepping on x86 is different to the step behaviour on arm64 afaik. On
>> A
(2013/11/11 19:58), Will Deacon wrote:
> On Mon, Nov 11, 2013 at 10:51:52AM +, Masami Hiramatsu wrote:
>> (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 i
On Mon, Nov 11, 2013 at 05:35:37AM +, Sandeepa Prabhu wrote:
> On 8 November 2013 22:26, Will Deacon wrote:
> >> diff --git a/arch/arm64/include/asm/kprobes.h
> >> b/arch/arm64/include/asm/kprobes.h
> >> new file mode 100644
> >> index 000..9b491d0
> >> --- /dev/null
> >> +++ b/arch/arm64
On Mon, Nov 11, 2013 at 10:51:52AM +, Masami Hiramatsu wrote:
> (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
(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
(2013/11/11 14:39), Sandeepa Prabhu wrote:
> On 9 November 2013 14:40, Masami Hiramatsu
> wrote:
>> (2013/11/09 1:56), Will Deacon wrote:
>>> Hi Sandeepa,
>>>
>>> On Thu, Oct 17, 2013 at 12:17:47PM +0100, Sandeepa Prabhu wrote:
Add support for basic kernel probes(kprobes), jump probes (jprobe
On 9 November 2013 14:40, Masami Hiramatsu
wrote:
> (2013/11/09 1:56), Will Deacon wrote:
>> Hi Sandeepa,
>>
>> On Thu, Oct 17, 2013 at 12:17:47PM +0100, Sandeepa Prabhu wrote:
>>> Add support for basic kernel probes(kprobes), jump probes (jprobes)
>>> for ARM64.
>>
>> I think this series will con
On 8 November 2013 22:26, Will Deacon wrote:
> Hi Sandeepa,
>
> On Thu, Oct 17, 2013 at 12:17:47PM +0100, Sandeepa Prabhu wrote:
>> Add support for basic kernel probes(kprobes), jump probes (jprobes)
>> for ARM64.
>
> I think this series will conflict quite heavily with the jump_label series,
> si
(2013/11/09 1:56), Will Deacon wrote:
> Hi Sandeepa,
>
> On Thu, Oct 17, 2013 at 12:17:47PM +0100, Sandeepa Prabhu wrote:
>> Add support for basic kernel probes(kprobes), jump probes (jprobes)
>> for ARM64.
>
> I think this series will conflict quite heavily with the jump_label series,
> since th
Hi Sandeepa,
On Thu, Oct 17, 2013 at 12:17:47PM +0100, Sandeepa Prabhu wrote:
> Add support for basic kernel probes(kprobes), jump probes (jprobes)
> for ARM64.
I think this series will conflict quite heavily with the jump_label series,
since they both introduce some common instruction manipulati
Add support for basic kernel probes(kprobes), jump probes (jprobes)
for ARM64.
Kprobes will utilize software breakpoint and single step debug
exceptions supported on ARM v8.
software breakpoint is placed at the probe address to trap the
kernel execution into kprobe handler.
ARM v8 support single
30 matches
Mail list logo
