[PATCH] sample/hw_breakpoint: avoid sample hw_breakpoint recursion for arm/arm64

[PATCH] sample/hw_breakpoint: avoid sample hw_breakpoint recursion for arm/arm64

[wangxu]

From: Wang Xu <wangxu72@huawei.com>

For x86/ppc, hw_breakpoint is triggered after the instruction is
executed.

For arm/arm64, which is triggered before the instruction executed.
Arm/arm64 skips the instruction by using single step. But it only
supports default overflow_handler.

This patch provides a chance to avoid sample hw_breakpoint recursion
for arm/arm64 by adding 'struct perf_event_attr.bp_step'.

Signed-off-by: Wang Xu <wangxu72@huawei.com>
---
 include/linux/perf_event.h              | 3 +++
 include/uapi/linux/perf_event.h         | 3 ++-
 samples/hw_breakpoint/data_breakpoint.c | 1 +
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 61448c1..f270eb7 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1024,6 +1024,9 @@ extern int perf_event_output(struct perf_event *event,
 		return true;
 	if (unlikely(event->overflow_handler == perf_event_output_backward))
 		return true;
+	/* avoid sample hw_breakpoint recursion */
+	if (unlikely(event->attr.bp_step))
+		return true;
 	return false;
 }
 
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index bb7b271..95b81c2 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -375,7 +375,8 @@ struct perf_event_attr {
 				ksymbol        :  1, /* include ksymbol events */
 				bpf_event      :  1, /* include bpf events */
 				aux_output     :  1, /* generate AUX records instead of events */
-				__reserved_1   : 32;
+				bp_step        :  1,
+				__reserved_1   : 31;
 
 	union {
 		__u32		wakeup_events;	  /* wakeup every n events */
diff --git a/samples/hw_breakpoint/data_breakpoint.c b/samples/hw_breakpoint/data_breakpoint.c
index c585047..9fe1351 100644
--- a/samples/hw_breakpoint/data_breakpoint.c
+++ b/samples/hw_breakpoint/data_breakpoint.c
@@ -46,6 +46,7 @@ static int __init hw_break_module_init(void)
 	attr.bp_addr = kallsyms_lookup_name(ksym_name);
 	attr.bp_len = HW_BREAKPOINT_LEN_4;
 	attr.bp_type = HW_BREAKPOINT_W | HW_BREAKPOINT_R;
+	attr.bp_step = true;
 
 	sample_hbp = register_wide_hw_breakpoint(&attr, sample_hbp_handler, NULL);
 	if (IS_ERR((void __force *)sample_hbp)) {
-- 
1.8.5.6

Re: [PATCH] sample/hw_breakpoint: avoid sample hw_breakpoint recursion for arm/arm64

[Peter Zijlstra]

On Mon, Sep 23, 2019 at 04:09:35PM +0800, wangxu wrote:
> From: Wang Xu <wangxu72@huawei.com>
> 
> For x86/ppc, hw_breakpoint is triggered after the instruction is
> executed.
> 
> For arm/arm64, which is triggered before the instruction executed.
> Arm/arm64 skips the instruction by using single step. But it only
> supports default overflow_handler.

Where is the recusion.. ?

> This patch provides a chance to avoid sample hw_breakpoint recursion
> for arm/arm64 by adding 'struct perf_event_attr.bp_step'.

This patch also lacks justification for why this needs to come with ABI
changes. There is also a distinct lack of comments.

> Signed-off-by: Wang Xu <wangxu72@huawei.com>
> ---
>  include/linux/perf_event.h              | 3 +++
>  include/uapi/linux/perf_event.h         | 3 ++-
>  samples/hw_breakpoint/data_breakpoint.c | 1 +
>  3 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 61448c1..f270eb7 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -1024,6 +1024,9 @@ extern int perf_event_output(struct perf_event *event,
>  		return true;
>  	if (unlikely(event->overflow_handler == perf_event_output_backward))
>  		return true;
> +	/* avoid sample hw_breakpoint recursion */
> +	if (unlikely(event->attr.bp_step))
> +		return true;

This is just _wrong_.. it says that every event with bp_step set always
is a 'default overflow handler', irrespective of what the overflow
handler actually is.

>  	return false;
>  }
>  

RE: [PATCH] sample/hw_breakpoint: avoid sample hw_breakpoint recursion for arm/arm64

[wangxu (AE)]

-----Original Message-----
From: Peter Zijlstra [mailto:peterz@infradead.org] 
Sent: Thursday, September 26, 2019 5:14 PM
To: wangxu (AE) <wangxu72@huawei.com>
Cc: mingo@redhat.com; acme@kernel.org; mark.rutland@arm.com; alexander.shishkin@linux.intel.com; namhyung@kernel.org; gregkh@linuxfoundation.org; tglx@linutronix.de; rfontana@redhat.com; allison@lohutok.net; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sample/hw_breakpoint: avoid sample hw_breakpoint recursion for arm/arm64

On Mon, Sep 23, 2019 at 04:09:35PM +0800, wangxu wrote:
> From: Wang Xu <wangxu72@huawei.com>
> 
> For x86/ppc, hw_breakpoint is triggered after the instruction is 
> executed.
> 
> For arm/arm64, which is triggered before the instruction executed.
> Arm/arm64 skips the instruction by using single step. But it only 
> supports default overflow_handler.

Where is the recusion.. ?

For arm/arm64, hw_breakpoint is triggered before the instruction executed.
When instruction_A is triggered, watchpoint_handler() will deal with this exception, and after return instruction_A will be triggerd ...

One using samples/hw_breakpoint/data_breakpoint.c in arm/arm64 will meet this problem.


> This patch provides a chance to avoid sample hw_breakpoint recursion 
> for arm/arm64 by adding 'struct perf_event_attr.bp_step'.

This patch also lacks justification for why this needs to come with ABI changes. There is also a distinct lack of comments.

I agree too. but have no better idea... 
This problem is really a big pit, especially for one not familiar with implementation differences in hw breakpoint for different architectures.



> Signed-off-by: Wang Xu <wangxu72@huawei.com>
> ---
>  include/linux/perf_event.h              | 3 +++
>  include/uapi/linux/perf_event.h         | 3 ++-
>  samples/hw_breakpoint/data_breakpoint.c | 1 +
>  3 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h 
> index 61448c1..f270eb7 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -1024,6 +1024,9 @@ extern int perf_event_output(struct perf_event *event,
>  		return true;
>  	if (unlikely(event->overflow_handler == perf_event_output_backward))
>  		return true;
> +	/* avoid sample hw_breakpoint recursion */
> +	if (unlikely(event->attr.bp_step))
> +		return true;

This is just _wrong_.. it says that every event with bp_step set always is a 'default overflow handler', irrespective of what the overflow handler actually is.

Thanks for comments.

Function is_default_overflow_handler() was introduced in 1879445dfa7bbd6fe21b09c5cc72f4934798afed , which is only be called in arch/arm[64]/kernel/hw_breakpoint.c, and will never be used in other arch/ (I think). 

But keeping is_default_overflow_handler() unchanged, changing ' if (is_default_overflow_handler(bp)) ' to ' if (is_default_overflow_handler(bp) || unlikely(event->attr.bp_step) ) ' will be better in arch/arm[64]/kernel/hw_breakpoint.c.

>  	return false;
>  }
>  

Re: [PATCH] sample/hw_breakpoint: avoid sample hw_breakpoint recursion for arm/arm64

[Will Deacon]

On Mon, Sep 23, 2019 at 04:09:35PM +0800, wangxu wrote:
> From: Wang Xu <wangxu72@huawei.com>
> 
> For x86/ppc, hw_breakpoint is triggered after the instruction is
> executed.
> 
> For arm/arm64, which is triggered before the instruction executed.
> Arm/arm64 skips the instruction by using single step. But it only
> supports default overflow_handler.
> 
> This patch provides a chance to avoid sample hw_breakpoint recursion
> for arm/arm64 by adding 'struct perf_event_attr.bp_step'.

Issues like this come up every so often [1], [2], [3] but I'm still of the
opinion that we should rip out the perf interface to hw_breakpoint on arm64
and implement something better directly for ptrace, which is what GDB cares
about. The current "let's convert to perf and back again" is a wreck, mainly
because we've not been able to abstract the debug trap behaviour across
different architectures. GDB just wants to poke registers, and this all
gets in the way of that.

Will

[1] https://lkml.org/lkml/2018/11/15/205
[2] https://lore.kernel.org/lkml/20160323181348.GA2149@arm.com/
[3] https://lkml.org/lkml/2016/3/21/504