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
29 matches
Mail list logo
