On 01/12, Pratyush Anand wrote:
>
> Hi Oleg,
>
> How can I generate a scenario to test:
>
> a) arch_uprobe_xol_was_trapped
> b) arch_uprobe_abort_xol
For example, you can probe something like
*(int *)NULL = 0;
See also the x86 test-case in https://lkml.org/lkml/2011/10/21/148
and the
On 01/12, Pratyush Anand wrote:
>
>
> On Friday 09 January 2015 11:29 PM, Oleg Nesterov wrote:
>> On 12/31, Pratyush Anand wrote:
>>>
>>> +int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe, struct mm_struct
>>> *mm,
>>> + unsigned long addr)
>>> +{
>>> + probe_opcode_t insn;
On 01/12, Pratyush Anand wrote:
On Friday 09 January 2015 11:29 PM, Oleg Nesterov wrote:
On 12/31, Pratyush Anand wrote:
+int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe, struct mm_struct
*mm,
+ unsigned long addr)
+{
+ probe_opcode_t insn;
+
+ insn =
On 01/12, Pratyush Anand wrote:
Hi Oleg,
How can I generate a scenario to test:
a) arch_uprobe_xol_was_trapped
b) arch_uprobe_abort_xol
For example, you can probe something like
*(int *)NULL = 0;
See also the x86 test-case in https://lkml.org/lkml/2011/10/21/148
and the whole
Hi Oleg,
How can I generate a scenario to test:
a) arch_uprobe_xol_was_trapped
b) arch_uprobe_abort_xol
~Pratyush
On Monday 12 January 2015 10:34 AM, Pratyush Anand wrote:
On Friday 09 January 2015 11:29 PM, Oleg Nesterov wrote:
On 12/31, Pratyush Anand wrote:
+int
On Friday 09 January 2015 11:29 PM, Oleg Nesterov wrote:
On 12/31, Pratyush Anand wrote:
+int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe, struct mm_struct *mm,
+ unsigned long addr)
+{
+ probe_opcode_t insn;
+
+ insn = *(probe_opcode_t *)(>insn[0]);
+
+
On Friday 09 January 2015 11:15 PM, Oleg Nesterov wrote:
On 01/08, Pratyush Anand wrote:
On Thursday 08 January 2015 10:33 PM, Will Deacon wrote:
I'm assuming that means you don't support compat (AArch32) tasks with this?
Hummm.. Yes, compat not yet supported.
I will come back on this.
On Friday 09 January 2015 11:29 PM, Oleg Nesterov wrote:
On 12/31, Pratyush Anand wrote:
+int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe, struct mm_struct *mm,
+ unsigned long addr)
+{
+ probe_opcode_t insn;
+
+ insn = *(probe_opcode_t *)(auprobe-insn[0]);
On Friday 09 January 2015 11:15 PM, Oleg Nesterov wrote:
On 01/08, Pratyush Anand wrote:
On Thursday 08 January 2015 10:33 PM, Will Deacon wrote:
I'm assuming that means you don't support compat (AArch32) tasks with this?
Hummm.. Yes, compat not yet supported.
I will come back on this.
Hi Oleg,
How can I generate a scenario to test:
a) arch_uprobe_xol_was_trapped
b) arch_uprobe_abort_xol
~Pratyush
On Monday 12 January 2015 10:34 AM, Pratyush Anand wrote:
On Friday 09 January 2015 11:29 PM, Oleg Nesterov wrote:
On 12/31, Pratyush Anand wrote:
+int
On 12/31, Pratyush Anand wrote:
>
> +int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe, struct mm_struct
> *mm,
> + unsigned long addr)
> +{
> + probe_opcode_t insn;
> +
> + insn = *(probe_opcode_t *)(>insn[0]);
> +
> + switch (arm_probe_decode_insn(insn, >ainsn)) {
On 01/08, Pratyush Anand wrote:
>
> On Thursday 08 January 2015 10:33 PM, Will Deacon wrote:
>>
>> I'm assuming that means you don't support compat (AArch32) tasks with this?
>
> Hummm.. Yes, compat not yet supported.
>
> I will come back on this.
I obviously do not know how difficult is to
On 12/31, Pratyush Anand wrote:
+int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe, struct mm_struct
*mm,
+ unsigned long addr)
+{
+ probe_opcode_t insn;
+
+ insn = *(probe_opcode_t *)(auprobe-insn[0]);
+
+ switch (arm_probe_decode_insn(insn,
On 01/08, Pratyush Anand wrote:
On Thursday 08 January 2015 10:33 PM, Will Deacon wrote:
I'm assuming that means you don't support compat (AArch32) tasks with this?
Hummm.. Yes, compat not yet supported.
I will come back on this.
I obviously do not know how difficult is to support the
On Thursday 08 January 2015 10:33 PM, Will Deacon wrote:
On Wed, Dec 31, 2014 at 03:21:24PM +, Pratyush Anand wrote:
This patch adds support for uprobe on ARM64 architecture.
Unit test for following has been done so far and they have been found
working
1. Normal instruction, which can be
On Wed, Dec 31, 2014 at 03:21:24PM +, Pratyush Anand wrote:
> This patch adds support for uprobe on ARM64 architecture.
>
> Unit test for following has been done so far and they have been found
> working
> 1. Normal instruction, which can be probed like sub, ldr, add etc.
> 2. Instructions
On Thursday 08 January 2015 10:33 PM, Will Deacon wrote:
On Wed, Dec 31, 2014 at 03:21:24PM +, Pratyush Anand wrote:
This patch adds support for uprobe on ARM64 architecture.
Unit test for following has been done so far and they have been found
working
1. Normal instruction, which can be
On Wed, Dec 31, 2014 at 03:21:24PM +, Pratyush Anand wrote:
This patch adds support for uprobe on ARM64 architecture.
Unit test for following has been done so far and they have been found
working
1. Normal instruction, which can be probed like sub, ldr, add etc.
2. Instructions which
On Monday 05 January 2015 12:10 AM, Oleg Nesterov wrote:
On 01/04, Pratyush Anand wrote:
On Friday 02 January 2015 10:53 PM, Oleg Nesterov wrote:
But the main question is: why do we need add/find_ss_context ?? Please
explain.
See arch/arm64/kernel/debug-monitors.c: call_step_hook
Unlike
On 01/04, Pratyush Anand wrote:
>
> On Friday 02 January 2015 10:53 PM, Oleg Nesterov wrote:
>> But the main question is: why do we need add/find_ss_context ?? Please
>> explain.
>>
>
> See arch/arm64/kernel/debug-monitors.c: call_step_hook
>
> Unlike breakpoint exception, there is no ESR info
On Friday 02 January 2015 10:53 PM, Oleg Nesterov wrote:
Hi Pratyush,
I'll try to actually read this patch (and the whole series) later, just
a couple of quick questions for now.
On 12/31, Pratyush Anand wrote:
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@
On Friday 02 January 2015 10:53 PM, Oleg Nesterov wrote:
Hi Pratyush,
I'll try to actually read this patch (and the whole series) later, just
a couple of quick questions for now.
On 12/31, Pratyush Anand wrote:
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@
On 01/04, Pratyush Anand wrote:
On Friday 02 January 2015 10:53 PM, Oleg Nesterov wrote:
But the main question is: why do we need add/find_ss_context ?? Please
explain.
See arch/arm64/kernel/debug-monitors.c: call_step_hook
Unlike breakpoint exception, there is no ESR info check for step
On Monday 05 January 2015 12:10 AM, Oleg Nesterov wrote:
On 01/04, Pratyush Anand wrote:
On Friday 02 January 2015 10:53 PM, Oleg Nesterov wrote:
But the main question is: why do we need add/find_ss_context ?? Please
explain.
See arch/arm64/kernel/debug-monitors.c: call_step_hook
Unlike
Hi Pratyush,
I'll try to actually read this patch (and the whole series) later, just
a couple of quick questions for now.
On 12/31, Pratyush Anand wrote:
>
> --- a/arch/arm64/include/asm/ptrace.h
> +++ b/arch/arm64/include/asm/ptrace.h
> @@ -205,6 +205,7 @@ static inline int
Hi Pratyush,
I'll try to actually read this patch (and the whole series) later, just
a couple of quick questions for now.
On 12/31, Pratyush Anand wrote:
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -205,6 +205,7 @@ static inline int valid_user_regs(struct
This patch adds support for uprobe on ARM64 architecture.
Unit test for following has been done so far and they have been found
working
1. Normal instruction, which can be probed like sub, ldr, add etc.
2. Instructions which can be simulated like ret.
3. uretprobe
Signed-off-by: Pratyush Anand
This patch adds support for uprobe on ARM64 architecture.
Unit test for following has been done so far and they have been found
working
1. Normal instruction, which can be probed like sub, ldr, add etc.
2. Instructions which can be simulated like ret.
3. uretprobe
Signed-off-by: Pratyush Anand
28 matches
Mail list logo
