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
On 18 November 2013 12:25, Sandeepa Prabhu sandeepa.pra...@linaro.org 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,
>> 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
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
On 15 November 2013 22:07, Will Deacon will.dea...@arm.com 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
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 if you
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
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
> >> >
> >> >
On Tue, Nov 12, 2013 at 06:52:51AM +, Sandeepa Prabhu wrote:
On 11 November 2013 16:51, Will Deacon will.dea...@arm.com wrote:
On Mon, Nov 11, 2013 at 05:35:37AM +, Sandeepa Prabhu wrote:
On 8 November 2013 22:26, Will Deacon will.dea...@arm.com wrote:
+#define MAX_INSN_SIZE
On Wed, Nov 13, 2013 at 03:55:42PM +, Sandeepa Prabhu wrote:
On 13 November 2013 20:01, Will Deacon will.dea...@arm.com 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
(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
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
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
>
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
(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
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
>
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
(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 as expected without some
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
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 fairly sure it won't work
On 13 November 2013 20:01, Will Deacon will.dea...@arm.com 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
(2013/11/13 1:59), Steven Rostedt wrote:
On Tue, 12 Nov 2013 16:25:26 +0530
Sandeepa Prabhu sandeepa.pra...@linaro.org 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
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
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
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
(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
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
On 12 November 2013 12:57, Masami Hiramatsu
masami.hiramatsu...@hitachi.com 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,
(2013/11/12 17:44), Sandeepa Prabhu wrote:
On 12 November 2013 12:57, Masami Hiramatsu
masami.hiramatsu...@hitachi.com 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
On 12 November 2013 15:47, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
(2013/11/12 17:44), Sandeepa Prabhu wrote:
On 12 November 2013 12:57, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
(2013/11/12 15:23), Sandeepa Prabhu wrote:
OK, I've ensured that the hw_breakpoint
(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 hardware breakpoint.
On Tue, 12 Nov 2013 16:25:26 +0530
Sandeepa Prabhu sandeepa.pra...@linaro.org 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
On 13 November 2013 12:25, Sandeepa Prabhu sandeepa.pra...@linaro.org 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
(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
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
>>> 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
>>
(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
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
> >> +++
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
(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
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 patched in a brk. We
On Mon, Nov 11, 2013 at 05:35:37AM +, Sandeepa Prabhu wrote:
On 8 November 2013 22:26, Will Deacon will.dea...@arm.com 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
+++
(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 in the kernel for
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
ARM, we have to
On 11 November 2013 16:51, Will Deacon will.dea...@arm.com wrote:
On Mon, Nov 11, 2013 at 05:35:37AM +, Sandeepa Prabhu wrote:
On 8 November 2013 22:26, Will Deacon will.dea...@arm.com wrote:
diff --git a/arch/arm64/include/asm/kprobes.h
b/arch/arm64/include/asm/kprobes.h
new file
(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 different to the step
(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
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
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,
>
On 8 November 2013 22:26, Will Deacon will.dea...@arm.com 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
On 9 November 2013 14:40, Masami Hiramatsu
masami.hiramatsu...@hitachi.com 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
(2013/11/11 14:39), Sandeepa Prabhu wrote:
On 9 November 2013 14:40, Masami Hiramatsu
masami.hiramatsu...@hitachi.com 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
(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
(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 they both
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
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
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
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
60 matches
Mail list logo
