From: Naveen N. Rao <hidden> Date: 2017-02-22 13:54:08
I'm including all patches (generic and powerpc changes) in
this series as suggested by Masami.
v1 patches:
https://marc.info/?l=linux-kernel&m=148718276424380https://marc.info/?l=linux-kernel&m=148723314105453&w=2
Patches 1 and 2 are the same as v1.
Patch 3 is updated to include a line in ftrace README.
Patch 4 is new.
Patch 5 is updated to consider ftrace README.
Thanks,
Naveen
Naveen N. Rao (5):
kretprobes: ensure probe location is at function entry
powerpc: kretprobes: override default function entry offset
trace/kprobes: allow return probes with offsets and absolute addresses
perf: kretprobes: offset from reloc_sym if kernel supports it
perf: powerpc: choose local entry point with kretprobes
arch/powerpc/kernel/kprobes.c | 9 ++++++
include/linux/kprobes.h | 1 +
kernel/kprobes.c | 13 ++++++++
kernel/trace/trace.c | 1 +
kernel/trace/trace_kprobe.c | 8 -----
tools/perf/arch/powerpc/util/sym-handling.c | 9 +++---
tools/perf/util/probe-event.c | 47 ++++++++++++++++++++++++-----
tools/perf/util/probe-event.h | 2 ++
8 files changed, 71 insertions(+), 19 deletions(-)
--
2.11.0
From: Naveen N. Rao <hidden> Date: 2017-02-22 13:54:18
kretprobes can be registered by specifying an absolute address or by
specifying offset to a symbol. However, we need to ensure this falls at
function entry so as to be able to determine the return address.
Validate the same during kretprobe registration. By default, there
should not be any offset from a function entry, as determined through a
kallsyms_lookup(). Introduce arch_function_offset_within_entry() as a
way for architectures to override this.
Signed-off-by: Naveen N. Rao <redacted>
---
include/linux/kprobes.h | 1 +
kernel/kprobes.c | 13 +++++++++++++
2 files changed, 14 insertions(+)
From: Naveen N. Rao <hidden> Date: 2017-02-22 13:54:29
perf now uses an offset from _text/_stext for kretprobes if the kernel
supports it, rather than the actual function name. As such, let's choose
the LEP for powerpc ABIv2 so as to ensure the probe gets hit. Do it only
if the kernel supports specifying offsets with kretprobes.
Signed-off-by: Naveen N. Rao <redacted>
---
tools/perf/arch/powerpc/util/sym-handling.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
@@ -79,11 +79,12 @@ void arch__fix_tev_from_maps(struct perf_probe_event *pev,*However,iftheuserspecifiesanoffset,wefallbacktousingthe*GEPsincealluserspaceapplications(objdump/readelf)showfunction*disassemblywithoffsetsfromtheGEP.-*-*Inaddition,weshouldn'tspecifyanoffsetforkretprobes.*/-if(pev->point.offset||(!pev->uprobes&&pev->point.retprobe)||-!map||!sym)+if(pev->point.offset||!map||!sym)+return;++/* For kretprobes, add an offset only if the kernel supports it */+if(!pev->uprobes&&pev->point.retprobe&&!is_kretprobe_offset_supported())return;lep_offset=PPC64_LOCAL_ENTRY_OFFSET(sym->arch_sym);
From: Naveen N. Rao <hidden> Date: 2017-02-22 13:54:42
With ABIv2, we offset 8 bytes into a function to get at the local entry
point.
Signed-off-by: Naveen N. Rao <redacted>
---
arch/powerpc/kernel/kprobes.c | 9 +++++++++
1 file changed, 9 insertions(+)
From: Naveen N. Rao <hidden> Date: 2017-02-22 13:54:55
We indicate support for accepting sym+offset with kretprobes through a
line in ftrace README. Parse the same to identify support and choose the
appropriate format for kprobe_events.
Signed-off-by: Naveen N. Rao <redacted>
---
tools/perf/util/probe-event.c | 47 ++++++++++++++++++++++++++++++++++++-------
tools/perf/util/probe-event.h | 2 ++
2 files changed, 42 insertions(+), 7 deletions(-)
@@ -757,7 +792,9 @@ post_process_kernel_probe_trace_events(struct probe_trace_event *tevs,}for(i=0;i<ntevs;i++){-if(!tevs[i].point.address||tevs[i].point.retprobe)+if(!tevs[i].point.address)+continue;+if(tevs[i].point.retprobe&&!is_kretprobe_offset_supported())continue;/* If we found a wrong one, mark it by NULL symbol */if(kprobe_warn_out_range(tevs[i].point.symbol,
@@ -1528,11 +1565,6 @@ static int parse_perf_probe_point(char *arg, struct perf_probe_event *pev)return-EINVAL;}-if(pp->retprobe&&!pp->function){-semantic_error("Return probe requires an entry function.\n");-return-EINVAL;-}-if((pp->offset||pp->line||pp->lazy_line)&&pp->retprobe){semantic_error("Offset/Line/Lazy pattern can't be used with ""return probe.\n");
@@ -2841,7 +2873,8 @@ static int find_probe_trace_events_from_map(struct perf_probe_event *pev,}/* Note that the symbols in the kmodule are not relocated */-if(!pev->uprobes&&!pp->retprobe&&!pev->target){+if(!pev->uprobes&&!pev->target&&+(!pp->retprobe||is_kretprobe_offset_supported())){reloc_sym=kernel_get_ref_reloc_sym();if(!reloc_sym){pr_warning("Relocated base symbol is not found!\n");
From: Naveen N. Rao <hidden> Date: 2017-02-22 13:55:09
Since the kernel includes many non-global functions with same names, we
will need to use offsets from other symbols (typically _text/_stext) or
absolute addresses to place return probes on specific functions. Also,
the core register_kretprobe() API never forbid use of offsets or
absolute addresses with kretprobes.
Allow its use with the trace infrastructure. To distinguish kernels that
support this, update ftrace README to explicitly call this out.
Signed-off-by: Naveen N. Rao <redacted>
---
kernel/trace/trace.c | 1 +
kernel/trace/trace_kprobe.c | 8 --------
2 files changed, 1 insertion(+), 8 deletions(-)
@@ -679,10 +679,6 @@ static int create_trace_kprobe(int argc, char **argv)return-EINVAL;}if(isdigit(argv[1][0])){-if(is_return){-pr_info("Return probe point must be a symbol.\n");-return-EINVAL;-}/* an address specified */ret=kstrtoul(&argv[1][0],0,(unsignedlong*)&addr);if(ret){
@@ -698,10 +694,6 @@ static int create_trace_kprobe(int argc, char **argv)pr_info("Failed to parse symbol.\n");returnret;}-if(offset&&is_return){-pr_info("Return probe must be used without offset.\n");-return-EINVAL;-}}argc-=2;argv+=2;
On Wed, 22 Feb 2017 19:23:40 +0530
"Naveen N. Rao" [off-list ref] wrote:
quoted hunk
We indicate support for accepting sym+offset with kretprobes through a
line in ftrace README. Parse the same to identify support and choose the
appropriate format for kprobe_events.
Signed-off-by: Naveen N. Rao <redacted>
---
tools/perf/util/probe-event.c | 47 ++++++++++++++++++++++++++++++++++++-------
tools/perf/util/probe-event.h | 2 ++
2 files changed, 42 insertions(+), 7 deletions(-)
Could you reuse (refactoring) probe_type_is_available() in probe-file.c to share
opening README file?
Others looks good to me :)
Thank you,
quoted hunk
+
static int
post_process_kernel_probe_trace_events(struct probe_trace_event *tevs,
int ntevs)
@@ -757,7 +792,9 @@ post_process_kernel_probe_trace_events(struct probe_trace_event *tevs, } for (i = 0; i < ntevs; i++) {- if (!tevs[i].point.address || tevs[i].point.retprobe)+ if (!tevs[i].point.address)+ continue;+ if (tevs[i].point.retprobe && !is_kretprobe_offset_supported()) continue; /* If we found a wrong one, mark it by NULL symbol */ if (kprobe_warn_out_range(tevs[i].point.symbol,
@@ -1528,11 +1565,6 @@ static int parse_perf_probe_point(char *arg, struct perf_probe_event *pev) return -EINVAL; }- if (pp->retprobe && !pp->function) {- semantic_error("Return probe requires an entry function.\n");- return -EINVAL;- }- if ((pp->offset || pp->line || pp->lazy_line) && pp->retprobe) { semantic_error("Offset/Line/Lazy pattern can't be used with " "return probe.\n");
@@ -2841,7 +2873,8 @@ static int find_probe_trace_events_from_map(struct perf_probe_event *pev, } /* Note that the symbols in the kmodule are not relocated */- if (!pev->uprobes && !pp->retprobe && !pev->target) {+ if (!pev->uprobes && !pev->target &&+ (!pp->retprobe || is_kretprobe_offset_supported())) { reloc_sym = kernel_get_ref_reloc_sym(); if (!reloc_sym) { pr_warning("Relocated base symbol is not found!\n");
From: Naveen N. Rao <hidden> Date: 2017-02-23 11:39:09
We indicate support for accepting sym+offset with kretprobes through a
line in ftrace README. Parse the same to identify support and choose the
appropriate format for kprobe_events.
Signed-off-by: Naveen N. Rao <redacted>
---
tools/perf/util/probe-event.c | 49 ++++++++++++++++++++++++++++++++++++-------
tools/perf/util/probe-event.h | 2 ++
2 files changed, 44 insertions(+), 7 deletions(-)
@@ -757,7 +794,9 @@ post_process_kernel_probe_trace_events(struct probe_trace_event *tevs,}for(i=0;i<ntevs;i++){-if(!tevs[i].point.address||tevs[i].point.retprobe)+if(!tevs[i].point.address)+continue;+if(tevs[i].point.retprobe&&!is_kretprobe_offset_supported())continue;/* If we found a wrong one, mark it by NULL symbol */if(kprobe_warn_out_range(tevs[i].point.symbol,
@@ -1528,11 +1567,6 @@ static int parse_perf_probe_point(char *arg, struct perf_probe_event *pev)return-EINVAL;}-if(pp->retprobe&&!pp->function){-semantic_error("Return probe requires an entry function.\n");-return-EINVAL;-}-if((pp->offset||pp->line||pp->lazy_line)&&pp->retprobe){semantic_error("Offset/Line/Lazy pattern can't be used with ""return probe.\n");
@@ -2841,7 +2875,8 @@ static int find_probe_trace_events_from_map(struct perf_probe_event *pev,}/* Note that the symbols in the kmodule are not relocated */-if(!pev->uprobes&&!pp->retprobe&&!pev->target){+if(!pev->uprobes&&!pev->target&&+(!pp->retprobe||is_kretprobe_offset_supported())){reloc_sym=kernel_get_ref_reloc_sym();if(!reloc_sym){pr_warning("Relocated base symbol is not found!\n");
From: Naveen N. Rao <hidden> Date: 2017-02-23 19:17:06
On 2017/02/23 06:10PM, Masami Hiramatsu wrote:
On Wed, 22 Feb 2017 19:23:40 +0530
"Naveen N. Rao" [off-list ref] wrote:
quoted
We indicate support for accepting sym+offset with kretprobes through a
line in ftrace README. Parse the same to identify support and choose the
appropriate format for kprobe_events.
Signed-off-by: Naveen N. Rao <redacted>
---
tools/perf/util/probe-event.c | 47 ++++++++++++++++++++++++++++++++++++-------
tools/perf/util/probe-event.h | 2 ++
2 files changed, 42 insertions(+), 7 deletions(-)
[snip]
Could you reuse (refactoring) probe_type_is_available() in probe-file.c to share
opening README file?
Done. I've sent patches to do that, please review.
Others looks good to me :)
Thanks. I hope that's an Ack for this patchset?
If so, and if Ingo/Michael agree, would it be ok to take the kernel bits
through the powerpc tree like we did for kprobe_exceptions_notify()
cleanup?
Regards,
Naveen
On Thu, 23 Feb 2017 17:07:24 +0530
"Naveen N. Rao" [off-list ref] wrote:
quoted hunk
We indicate support for accepting sym+offset with kretprobes through a
line in ftrace README. Parse the same to identify support and choose the
appropriate format for kprobe_events.
Signed-off-by: Naveen N. Rao <redacted>
---
tools/perf/util/probe-event.c | 49 ++++++++++++++++++++++++++++++++++++-------
tools/perf/util/probe-event.h | 2 ++
2 files changed, 44 insertions(+), 7 deletions(-)
Hmm, I think you can do more than that.
Can you reuse probe_type_is_available() to scan README?
I think we can have something like scan_ftrace_readme() in probe-file.c
to scan all the options and cache the results.
probe_type_is_available() and kreprobe_offset_is_available()
just returns cached result or scan it in first call.(I would like to
ask you to do it in probe-file.c too)
Thank you,
quoted hunk
+
static int
post_process_kernel_probe_trace_events(struct probe_trace_event *tevs,
int ntevs)
@@ -757,7 +794,9 @@ post_process_kernel_probe_trace_events(struct probe_trace_event *tevs, } for (i = 0; i < ntevs; i++) {- if (!tevs[i].point.address || tevs[i].point.retprobe)+ if (!tevs[i].point.address)+ continue;+ if (tevs[i].point.retprobe && !is_kretprobe_offset_supported()) continue; /* If we found a wrong one, mark it by NULL symbol */ if (kprobe_warn_out_range(tevs[i].point.symbol,
@@ -1528,11 +1567,6 @@ static int parse_perf_probe_point(char *arg, struct perf_probe_event *pev) return -EINVAL; }- if (pp->retprobe && !pp->function) {- semantic_error("Return probe requires an entry function.\n");- return -EINVAL;- }- if ((pp->offset || pp->line || pp->lazy_line) && pp->retprobe) { semantic_error("Offset/Line/Lazy pattern can't be used with " "return probe.\n");
@@ -2841,7 +2875,8 @@ static int find_probe_trace_events_from_map(struct perf_probe_event *pev, } /* Note that the symbols in the kmodule are not relocated */- if (!pev->uprobes && !pp->retprobe && !pev->target) {+ if (!pev->uprobes && !pev->target &&+ (!pp->retprobe || is_kretprobe_offset_supported())) { reloc_sym = kernel_get_ref_reloc_sym(); if (!reloc_sym) { pr_warning("Relocated base symbol is not found!\n");
On Fri, 24 Feb 2017 00:46:08 +0530
"Naveen N. Rao" [off-list ref] wrote:
On 2017/02/23 06:10PM, Masami Hiramatsu wrote:
quoted
On Wed, 22 Feb 2017 19:23:40 +0530
"Naveen N. Rao" [off-list ref] wrote:
quoted
We indicate support for accepting sym+offset with kretprobes through a
line in ftrace README. Parse the same to identify support and choose the
appropriate format for kprobe_events.
Signed-off-by: Naveen N. Rao <redacted>
---
tools/perf/util/probe-event.c | 47 ++++++++++++++++++++++++++++++++++++-------
tools/perf/util/probe-event.h | 2 ++
2 files changed, 42 insertions(+), 7 deletions(-)
[snip]
quoted
Could you reuse (refactoring) probe_type_is_available() in probe-file.c to share
opening README file?
Done. I've sent patches to do that, please review.
OK.
quoted
Others looks good to me :)
Thanks. I hope that's an Ack for this patchset?
OK, for 1/5, 2/5, 3/5, and 5/5;
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
And could you make v4 series including all patches? (Not only updates)
If so, and if Ingo/Michael agree, would it be ok to take the kernel bits
through the powerpc tree like we did for kprobe_exceptions_notify()
cleanup?
If it is not urgent (yes, it seems) and since it changes arch independent
parts, I think this series should finally go through Ingo's tree.
Thank you,
--
Masami Hiramatsu [off-list ref]
From: Arnaldo Carvalho de Melo <acme@kernel.org> Date: 2017-02-24 19:57:33
Em Wed, Feb 22, 2017 at 07:23:38PM +0530, Naveen N. Rao escreveu:
With ABIv2, we offset 8 bytes into a function to get at the local entry
point.
So, I think I can carry the first one via Ingo, etc, what about this
one?
Is it ok for me to process it?
Seems simple enough, has been thru a lot of discussion, but would be
better if it was Reviewed-by the PPC maintainers or else just processed
by them.
Please advise,
- Arnaldo
From: Arnaldo Carvalho de Melo <acme@kernel.org> Date: 2017-02-24 20:11:14
Em Sat, Feb 25, 2017 at 02:29:17AM +0900, Masami Hiramatsu escreveu:
On Fri, 24 Feb 2017 00:46:08 +0530
"Naveen N. Rao" [off-list ref] wrote:
quoted
Thanks. I hope that's an Ack for this patchset?
OK, for 1/5, 2/5, 3/5, and 5/5;
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
And could you make v4 series including all patches? (Not only updates)
So, to make progress I processed these:
[acme@jouet linux]$ git log --oneline -3
eb55608340b7 perf probe: Generalize probe event file open routine
859d718fac06 trace/kprobes: Allow return probes with offsets and absolute addresses
a10489121c81 kretprobes: Ensure probe location is at function entry
[acme@jouet linux]$
Waiting for Naveen to react to these last minute considerations from
Masami and for the Ack from the PPC guys about "[PATCH v2 2/5] powerpc:
kretprobes: override default function entry offset".
- Arnaldo
On Fri, 24 Feb 2017 17:11:03 -0300
Arnaldo Carvalho de Melo [off-list ref] wrote:
Em Sat, Feb 25, 2017 at 02:29:17AM +0900, Masami Hiramatsu escreveu:
quoted
On Fri, 24 Feb 2017 00:46:08 +0530
"Naveen N. Rao" [off-list ref] wrote:
quoted
Thanks. I hope that's an Ack for this patchset?
OK, for 1/5, 2/5, 3/5, and 5/5;
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
And could you make v4 series including all patches? (Not only updates)
So, to make progress I processed these:
[acme@jouet linux]$ git log --oneline -3
eb55608340b7 perf probe: Generalize probe event file open routine
859d718fac06 trace/kprobes: Allow return probes with offsets and absolute addresses
a10489121c81 kretprobes: Ensure probe location is at function entry
[acme@jouet linux]$
Waiting for Naveen to react to these last minute considerations from
Masami and for the Ack from the PPC guys about "[PATCH v2 2/5] powerpc:
kretprobes: override default function entry offset".
Thanks Arnaldo!!
Naveen, please update your ppc and perf patches and send it to Arnaldo.
I'm happy to review it.
--
Masami Hiramatsu [off-list ref]
From: Steven Rostedt <rostedt@goodmis.org> Date: 2017-02-27 16:42:15
On Wed, 22 Feb 2017 19:23:39 +0530
"Naveen N. Rao" [off-list ref] wrote:
quoted hunk
Since the kernel includes many non-global functions with same names, we
will need to use offsets from other symbols (typically _text/_stext) or
absolute addresses to place return probes on specific functions. Also,
the core register_kretprobe() API never forbid use of offsets or
absolute addresses with kretprobes.
Allow its use with the trace infrastructure. To distinguish kernels that
support this, update ftrace README to explicitly call this out.
Signed-off-by: Naveen N. Rao <redacted>
---
kernel/trace/trace.c | 1 +
kernel/trace/trace_kprobe.c | 8 --------
2 files changed, 1 insertion(+), 8 deletions(-)
@@ -679,10 +679,6 @@ static int create_trace_kprobe(int argc, char **argv)return-EINVAL;}if(isdigit(argv[1][0])){-if(is_return){-pr_info("Return probe point must be a symbol.\n");-return-EINVAL;-}/* an address specified */ret=kstrtoul(&argv[1][0],0,(unsignedlong*)&addr);if(ret){
@@ -698,10 +694,6 @@ static int create_trace_kprobe(int argc, char **argv)pr_info("Failed to parse symbol.\n");returnret;}-if(offset&&is_return){-pr_info("Return probe must be used without offset.\n");-return-EINVAL;-}
I understand that your retprobes will now have an offset, but I'm
worried we are removing informative errors. For those archs that don't
allow an offset, will we still get the error telling users that offsets
are not allowed?
I don't want to lose informative error handling.
-- Steve
Let's not remove the warning about offsets and return probes when the
offset is invalid.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
---
@@ -695,6 +695,11 @@ static int create_trace_kprobe(int argc, char **argv)pr_info("Failed to parse symbol.\n");returnret;}+if(offset&&is_return&&+!arch_function_offset_within_entry(offset)){+pr_info("Given offset is not valid for return probe.\n");+return-EINVAL;+}}argc-=2;argv+=2;
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2017-02-27 18:58:21
Arnaldo Carvalho de Melo [off-list ref] writes:
Em Wed, Feb 22, 2017 at 07:23:38PM +0530, Naveen N. Rao escreveu:
quoted
With ABIv2, we offset 8 bytes into a function to get at the local entry
point.
So, I think I can carry the first one via Ingo, etc, what about this
one?
Is it ok for me to process it?
Yes please.
Seems simple enough, has been thru a lot of discussion, but would be
better if it was Reviewed-by the PPC maintainers or else just processed
by them.
Please advise,
I think it's best if you take it with patch 1. I realise they could go
separately, but they make more sense together I think.
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
cheers
@@ -695,6 +695,11 @@ static int create_trace_kprobe(int argc, char **argv)pr_info("Failed to parse symbol.\n");returnret;}+if(offset&&is_return&&+!arch_function_offset_within_entry(offset)){+pr_info("Given offset is not valid for return probe.\n");+return-EINVAL;+}}argc-=2;argv+=2;
@@ -695,6 +695,11 @@ static int create_trace_kprobe(int argc, char **argv)pr_info("Failed to parse symbol.\n");returnret;}+if(offset&&is_return&&+!arch_function_offset_within_entry(offset)){+pr_info("Given offset is not valid for return probe.\n");+return-EINVAL;+}}argc-=2;argv+=2;
From: Naveen N. Rao <hidden> Date: 2017-03-01 16:42:21
On 2017/02/25 02:12AM, Masami Hiramatsu wrote:
On Thu, 23 Feb 2017 17:07:24 +0530
"Naveen N. Rao" [off-list ref] wrote:
quoted
We indicate support for accepting sym+offset with kretprobes through a
line in ftrace README. Parse the same to identify support and choose the
appropriate format for kprobe_events.
Signed-off-by: Naveen N. Rao <redacted>
---
tools/perf/util/probe-event.c | 49 ++++++++++++++++++++++++++++++++++++-------
tools/perf/util/probe-event.h | 2 ++
2 files changed, 44 insertions(+), 7 deletions(-)
Hmm, I think you can do more than that.
Can you reuse probe_type_is_available() to scan README?
I think we can have something like scan_ftrace_readme() in probe-file.c
to scan all the options and cache the results.
probe_type_is_available() and kreprobe_offset_is_available()
just returns cached result or scan it in first call.(I would like to
ask you to do it in probe-file.c too)
Ok sure, that makes sense. I see that we only ever care about support
for hex type, so I will add a separate routine to only look for that and
the newly added kretprobe offset support.
- Naveen
From: Naveen N. Rao <hidden> Date: 2017-03-01 19:09:47
On 2017/02/25 08:55AM, Masami Hiramatsu wrote:
On Fri, 24 Feb 2017 17:11:03 -0300
Arnaldo Carvalho de Melo [off-list ref] wrote:
quoted
Em Sat, Feb 25, 2017 at 02:29:17AM +0900, Masami Hiramatsu escreveu:
quoted
On Fri, 24 Feb 2017 00:46:08 +0530
"Naveen N. Rao" [off-list ref] wrote:
quoted
Thanks. I hope that's an Ack for this patchset?
OK, for 1/5, 2/5, 3/5, and 5/5;
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
And could you make v4 series including all patches? (Not only updates)
So, to make progress I processed these:
[acme@jouet linux]$ git log --oneline -3
eb55608340b7 perf probe: Generalize probe event file open routine
859d718fac06 trace/kprobes: Allow return probes with offsets and absolute addresses
a10489121c81 kretprobes: Ensure probe location is at function entry
[acme@jouet linux]$
Waiting for Naveen to react to these last minute considerations from
Masami and for the Ack from the PPC guys about "[PATCH v2 2/5] powerpc:
kretprobes: override default function entry offset".
Thanks Arnaldo!
Sorry, couldn't get to this sooner as I was off for a day...
I see that you've picked up 3 of the patches and Ananth/Michael have
acked the powerpc patch.
I will post the remaining ones tonight/tomorrow.
Thanks Arnaldo!!
Naveen, please update your ppc and perf patches and send it to Arnaldo.
I'm happy to review it.
Sure thanks, I'll work on those tonight/tomorrow.
- Naveen
From: Arnaldo Carvalho de Melo <acme@kernel.org> Date: 2017-03-02 19:31:23
Em Thu, Mar 02, 2017 at 11:25:04PM +0530, Naveen N. Rao escreveu:
On 2017/02/24 05:11PM, Arnaldo Carvalho de Melo wrote:
quoted
Em Sat, Feb 25, 2017 at 02:29:17AM +0900, Masami Hiramatsu escreveu:
quoted
On Fri, 24 Feb 2017 00:46:08 +0530
"Naveen N. Rao" [off-list ref] wrote:
quoted
Thanks. I hope that's an Ack for this patchset?
OK, for 1/5, 2/5, 3/5, and 5/5;
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
And could you make v4 series including all patches? (Not only updates)
So, to make progress I processed these:
[acme@jouet linux]$ git log --oneline -3
eb55608340b7 perf probe: Generalize probe event file open routine
859d718fac06 trace/kprobes: Allow return probes with offsets and absolute addresses
a10489121c81 kretprobes: Ensure probe location is at function entry
[acme@jouet linux]$
Waiting for Naveen to react to these last minute considerations from
Masami and for the Ack from the PPC guys about "[PATCH v2 2/5] powerpc:
kretprobes: override default function entry offset".
Arnaldo,
I am posting the remaining three patches in this series. These three
patches are on top of the above 3 patches you have processed and the
other powerpc kretprobes patch (v2 2/5).
Masami,
Kindly review and let me know if this is fine.
Will process after Masami-san has time to review it,
Thanks,
- Arnaldo
From: Naveen N. Rao <hidden> Date: 2017-03-02 21:25:38
perf now uses an offset from _text/_stext for kretprobes if the kernel
supports it, rather than the actual function name. As such, let's choose
the LEP for powerpc ABIv2 so as to ensure the probe gets hit. Do it only
if the kernel supports specifying offsets with kretprobes.
Signed-off-by: Naveen N. Rao <redacted>
---
tools/perf/arch/powerpc/util/sym-handling.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
@@ -79,11 +80,12 @@ void arch__fix_tev_from_maps(struct perf_probe_event *pev,*However,iftheuserspecifiesanoffset,wefallbacktousingthe*GEPsincealluserspaceapplications(objdump/readelf)showfunction*disassemblywithoffsetsfromtheGEP.-*-*Inaddition,weshouldn'tspecifyanoffsetforkretprobes.*/-if(pev->point.offset||(!pev->uprobes&&pev->point.retprobe)||-!map||!sym)+if(pev->point.offset||!map||!sym)+return;++/* For kretprobes, add an offset only if the kernel supports it */+if(!pev->uprobes&&pev->point.retprobe&&!kretprobe_offset_is_supported())return;lep_offset=PPC64_LOCAL_ENTRY_OFFSET(sym->arch_sym);
From: Naveen N. Rao <hidden> Date: 2017-03-02 23:08:58
We indicate support for accepting sym+offset with kretprobes through a
line in ftrace README. Parse the same to identify support and choose the
appropriate format for kprobe_events.
Signed-off-by: Naveen N. Rao <redacted>
---
tools/perf/util/probe-event.c | 12 +++++-------
tools/perf/util/probe-file.c | 7 +++++++
tools/perf/util/probe-file.h | 1 +
3 files changed, 13 insertions(+), 7 deletions(-)
@@ -757,7 +757,9 @@ post_process_kernel_probe_trace_events(struct probe_trace_event *tevs,}for(i=0;i<ntevs;i++){-if(!tevs[i].point.address||tevs[i].point.retprobe)+if(!tevs[i].point.address)+continue;+if(tevs[i].point.retprobe&&!kretprobe_offset_is_supported())continue;/* If we found a wrong one, mark it by NULL symbol */if(kprobe_warn_out_range(tevs[i].point.symbol,
@@ -1528,11 +1530,6 @@ static int parse_perf_probe_point(char *arg, struct perf_probe_event *pev)return-EINVAL;}-if(pp->retprobe&&!pp->function){-semantic_error("Return probe requires an entry function.\n");-return-EINVAL;-}-if((pp->offset||pp->line||pp->lazy_line)&&pp->retprobe){semantic_error("Offset/Line/Lazy pattern can't be used with ""return probe.\n");
@@ -2841,7 +2838,8 @@ static int find_probe_trace_events_from_map(struct perf_probe_event *pev,}/* Note that the symbols in the kmodule are not relocated */-if(!pev->uprobes&&!pp->retprobe&&!pev->target){+if(!pev->uprobes&&!pev->target&&+(!pp->retprobe||kretprobe_offset_is_supported())){reloc_sym=kernel_get_ref_reloc_sym();if(!reloc_sym){pr_warning("Relocated base symbol is not found!\n");
From: Naveen N. Rao <hidden> Date: 2017-03-03 00:31:46
On 2017/02/24 05:11PM, Arnaldo Carvalho de Melo wrote:
Em Sat, Feb 25, 2017 at 02:29:17AM +0900, Masami Hiramatsu escreveu:
quoted
On Fri, 24 Feb 2017 00:46:08 +0530
"Naveen N. Rao" [off-list ref] wrote:
quoted
Thanks. I hope that's an Ack for this patchset?
OK, for 1/5, 2/5, 3/5, and 5/5;
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
And could you make v4 series including all patches? (Not only updates)
So, to make progress I processed these:
[acme@jouet linux]$ git log --oneline -3
eb55608340b7 perf probe: Generalize probe event file open routine
859d718fac06 trace/kprobes: Allow return probes with offsets and absolute addresses
a10489121c81 kretprobes: Ensure probe location is at function entry
[acme@jouet linux]$
Waiting for Naveen to react to these last minute considerations from
Masami and for the Ack from the PPC guys about "[PATCH v2 2/5] powerpc:
kretprobes: override default function entry offset".
Arnaldo,
I am posting the remaining three patches in this series. These three
patches are on top of the above 3 patches you have processed and the
other powerpc kretprobes patch (v2 2/5).
Masami,
Kindly review and let me know if this is fine.
Thanks,
Naveen
---
Naveen N. Rao (3):
perf: probe: factor out the ftrace README scanning
perf: kretprobes: offset from reloc_sym if kernel supports it
perf: powerpc: choose local entry point with kretprobes
tools/perf/arch/powerpc/util/sym-handling.c | 10 ++--
tools/perf/util/probe-event.c | 12 ++---
tools/perf/util/probe-file.c | 77 ++++++++++++++++-------------
tools/perf/util/probe-file.h | 1 +
4 files changed, 56 insertions(+), 44 deletions(-)
--
2.11.1
From: Naveen N. Rao <hidden> Date: 2017-03-03 00:32:47
Simplify and separate out the ftrace README scanning logic into a
separate helper. This is used subsequently to scan for all patterns of
interest and to cache the result.
Since we are only interested in availability of probe argument type x,
we will only scan for that.
Signed-off-by: Naveen N. Rao <redacted>
---
tools/perf/util/probe-file.c | 70 +++++++++++++++++++++++---------------------
1 file changed, 37 insertions(+), 33 deletions(-)
@@ -877,35 +877,31 @@ int probe_cache__show_all_caches(struct strfilter *filter)return0;}+enumftrace_readme{+FTRACE_README_PROBE_TYPE_X=0,+FTRACE_README_END,+};+staticstruct{constchar*pattern;-boolavail;-boolchecked;-}probe_type_table[]={-#define DEFINE_TYPE(idx, pat, def_avail) \-[idx]={.pattern=pat,.avail=(def_avail)}-DEFINE_TYPE(PROBE_TYPE_U,"* u8/16/32/64,*",true),-DEFINE_TYPE(PROBE_TYPE_S,"* s8/16/32/64,*",true),-DEFINE_TYPE(PROBE_TYPE_X,"* x8/16/32/64,*",false),-DEFINE_TYPE(PROBE_TYPE_STRING,"* string,*",true),-DEFINE_TYPE(PROBE_TYPE_BITFIELD,-"* b<bit-width>@<bit-offset>/<container-size>",true),+boolavail;+}ftrace_readme_table[]={+#define DEFINE_TYPE(idx, pat) \+[idx]={.pattern=pat,.avail=false}+DEFINE_TYPE(FTRACE_README_PROBE_TYPE_X,"*type: * x8/16/32/64,*"),};-boolprobe_type_is_available(enumprobe_typetype)+staticboolscan_ftrace_readme(enumftrace_readmetype){+intfd;FILE*fp;char*buf=NULL;size_tlen=0;-booltarget_line=false;-boolret=probe_type_table[type].avail;-intfd;+boolret=false;+staticboolscanned=false;-if(type>=PROBE_TYPE_END)-returnfalse;-/* We don't have to check the type which supported by default */-if(ret||probe_type_table[type].checked)-returnret;+if(scanned)+gotoresult;fd=open_trace_file("README",false);if(fd<0)
@@ -917,21 +913,29 @@ bool probe_type_is_available(enum probe_type type)returnret;}-while(getline(&buf,&len,fp)>0&&!ret){-if(!target_line){-target_line=!!strstr(buf," type: ");-if(!target_line)-continue;-}elseif(strstr(buf,"\t ")!=buf)-break;-ret=strglobmatch(buf,probe_type_table[type].pattern);-}-/* Cache the result */-probe_type_table[type].checked=true;-probe_type_table[type].avail=ret;+while(getline(&buf,&len,fp)>0)+for(enumftrace_readmei=0;i<FTRACE_README_END;i++)+if(!ftrace_readme_table[i].avail)+ftrace_readme_table[i].avail=+strglobmatch(buf,ftrace_readme_table[i].pattern);+scanned=true;fclose(fp);free(buf);-returnret;+result:+if(type>=FTRACE_README_END)+returnfalse;++returnftrace_readme_table[type].avail;+}++boolprobe_type_is_available(enumprobe_typetype)+{+if(type>=PROBE_TYPE_END)+returnfalse;+elseif(type==PROBE_TYPE_X)+returnscan_ftrace_readme(FTRACE_README_PROBE_TYPE_X);++returntrue;}
On Thu, 2 Mar 2017 23:25:05 +0530
"Naveen N. Rao" [off-list ref] wrote:
Simplify and separate out the ftrace README scanning logic into a
separate helper. This is used subsequently to scan for all patterns of
interest and to cache the result.
Since we are only interested in availability of probe argument type x,
we will only scan for that.
Ah, OK, this can simplify and shorten the actual scanning time.
If there are any needs for checking those in the future, we can
add it again at that moment.
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Thank you!
@@ -877,35 +877,31 @@ int probe_cache__show_all_caches(struct strfilter *filter)return0;}+enumftrace_readme{+FTRACE_README_PROBE_TYPE_X=0,+FTRACE_README_END,+};+staticstruct{constchar*pattern;-boolavail;-boolchecked;-}probe_type_table[]={-#define DEFINE_TYPE(idx, pat, def_avail) \-[idx]={.pattern=pat,.avail=(def_avail)}-DEFINE_TYPE(PROBE_TYPE_U,"* u8/16/32/64,*",true),-DEFINE_TYPE(PROBE_TYPE_S,"* s8/16/32/64,*",true),-DEFINE_TYPE(PROBE_TYPE_X,"* x8/16/32/64,*",false),-DEFINE_TYPE(PROBE_TYPE_STRING,"* string,*",true),-DEFINE_TYPE(PROBE_TYPE_BITFIELD,-"* b<bit-width>@<bit-offset>/<container-size>",true),+boolavail;+}ftrace_readme_table[]={+#define DEFINE_TYPE(idx, pat) \+[idx]={.pattern=pat,.avail=false}+DEFINE_TYPE(FTRACE_README_PROBE_TYPE_X,"*type: * x8/16/32/64,*"),};-boolprobe_type_is_available(enumprobe_typetype)+staticboolscan_ftrace_readme(enumftrace_readmetype){+intfd;FILE*fp;char*buf=NULL;size_tlen=0;-booltarget_line=false;-boolret=probe_type_table[type].avail;-intfd;+boolret=false;+staticboolscanned=false;-if(type>=PROBE_TYPE_END)-returnfalse;-/* We don't have to check the type which supported by default */-if(ret||probe_type_table[type].checked)-returnret;+if(scanned)+gotoresult;fd=open_trace_file("README",false);if(fd<0)
@@ -917,21 +913,29 @@ bool probe_type_is_available(enum probe_type type)returnret;}-while(getline(&buf,&len,fp)>0&&!ret){-if(!target_line){-target_line=!!strstr(buf," type: ");-if(!target_line)-continue;-}elseif(strstr(buf,"\t ")!=buf)-break;-ret=strglobmatch(buf,probe_type_table[type].pattern);-}-/* Cache the result */-probe_type_table[type].checked=true;-probe_type_table[type].avail=ret;+while(getline(&buf,&len,fp)>0)+for(enumftrace_readmei=0;i<FTRACE_README_END;i++)+if(!ftrace_readme_table[i].avail)+ftrace_readme_table[i].avail=+strglobmatch(buf,ftrace_readme_table[i].pattern);+scanned=true;fclose(fp);free(buf);-returnret;+result:+if(type>=FTRACE_README_END)+returnfalse;++returnftrace_readme_table[type].avail;+}++boolprobe_type_is_available(enumprobe_typetype)+{+if(type>=PROBE_TYPE_END)+returnfalse;+elseif(type==PROBE_TYPE_X)+returnscan_ftrace_readme(FTRACE_README_PROBE_TYPE_X);++returntrue;}
On Thu, 2 Mar 2017 23:25:07 +0530
"Naveen N. Rao" [off-list ref] wrote:
perf now uses an offset from _text/_stext for kretprobes if the kernel
supports it, rather than the actual function name. As such, let's choose
the LEP for powerpc ABIv2 so as to ensure the probe gets hit. Do it only
if the kernel supports specifying offsets with kretprobes.
Looks good to me.
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Thanks!
@@ -79,11 +80,12 @@ void arch__fix_tev_from_maps(struct perf_probe_event *pev,*However,iftheuserspecifiesanoffset,wefallbacktousingthe*GEPsincealluserspaceapplications(objdump/readelf)showfunction*disassemblywithoffsetsfromtheGEP.-*-*Inaddition,weshouldn'tspecifyanoffsetforkretprobes.*/-if(pev->point.offset||(!pev->uprobes&&pev->point.retprobe)||-!map||!sym)+if(pev->point.offset||!map||!sym)+return;++/* For kretprobes, add an offset only if the kernel supports it */+if(!pev->uprobes&&pev->point.retprobe&&!kretprobe_offset_is_supported())return;lep_offset=PPC64_LOCAL_ENTRY_OFFSET(sym->arch_sym);
On Thu, 2 Mar 2017 23:25:06 +0530
"Naveen N. Rao" [off-list ref] wrote:
We indicate support for accepting sym+offset with kretprobes through a
line in ftrace README. Parse the same to identify support and choose the
appropriate format for kprobe_events.
Could you give us an example of this change here? :)
for example, comment of commit 613f050d68a8 .
I think the code is OK, but we need actual example of result.
Thanks,
@@ -757,7 +757,9 @@ post_process_kernel_probe_trace_events(struct probe_trace_event *tevs,}for(i=0;i<ntevs;i++){-if(!tevs[i].point.address||tevs[i].point.retprobe)+if(!tevs[i].point.address)+continue;+if(tevs[i].point.retprobe&&!kretprobe_offset_is_supported())continue;/* If we found a wrong one, mark it by NULL symbol */if(kprobe_warn_out_range(tevs[i].point.symbol,
@@ -1528,11 +1530,6 @@ static int parse_perf_probe_point(char *arg, struct perf_probe_event *pev)return-EINVAL;}-if(pp->retprobe&&!pp->function){-semantic_error("Return probe requires an entry function.\n");-return-EINVAL;-}-if((pp->offset||pp->line||pp->lazy_line)&&pp->retprobe){semantic_error("Offset/Line/Lazy pattern can't be used with ""return probe.\n");
@@ -2841,7 +2838,8 @@ static int find_probe_trace_events_from_map(struct perf_probe_event *pev,}/* Note that the symbols in the kmodule are not relocated */-if(!pev->uprobes&&!pp->retprobe&&!pev->target){+if(!pev->uprobes&&!pev->target&&+(!pp->retprobe||kretprobe_offset_is_supported())){reloc_sym=kernel_get_ref_reloc_sym();if(!reloc_sym){pr_warning("Relocated base symbol is not found!\n");
On Sat, 4 Mar 2017 09:49:11 +0900
Masami Hiramatsu [off-list ref] wrote:
On Thu, 2 Mar 2017 23:25:06 +0530
"Naveen N. Rao" [off-list ref] wrote:
quoted
We indicate support for accepting sym+offset with kretprobes through a
line in ftrace README. Parse the same to identify support and choose the
appropriate format for kprobe_events.
Could you give us an example of this change here? :)
for example, comment of commit 613f050d68a8 .
I think the code is OK, but we need actual example of result.
Hi Naveen,
I've tried following commands
$ grep "[Tt] user_read$" /proc/kallsyms
0000000000000000 T user_read
0000000000000000 t user_read
$ sudo ./perf probe -D user_read%return
r:probe/user_read _text+3539616
r:probe/user_read_1 _text+3653408
OK, looks good. However, when I set the retprobes, I got an error.
$ sudo ./perf probe -a user_read%return
Failed to write event: Invalid argument
Error: Failed to add events.
And kernel rejected that.
$ dmesg -k | tail -n 1
[ 850.315068] Given offset is not valid for return probe.
Hmm, curious..
I tried normal probes
$ sudo ./perf probe -D user_read
p:probe/user_read _text+3539616
p:probe/user_read_1 _text+3653408
$ sudo ./perf probe -a user_read
Added new events:
probe:user_read (on user_read)
probe:user_read_1 (on user_read)
You can now use it in all perf tools, such as:
perf record -e probe:user_read_1 -aR sleep 1
It works!
$ sudo ./perf probe -l
probe:user_read (on user_read@security/keys/user_defined.c)
probe:user_read_1 (on user_read@selinux/ss/policydb.c)
$ sudo cat /sys/kernel/debug/kprobes/list
ffffffff9237bf20 k user_read+0x0 [DISABLED][FTRACE]
ffffffff923602a0 k user_read+0x0 [DISABLED][FTRACE]
So, the both "_text+3539616" and "_text+3653408" are correctly located
on the entry address of user_read functions. It seems kernel-side
symbol+offset check is wrong.
Thank you,
@@ -757,7 +757,9 @@ post_process_kernel_probe_trace_events(struct probe_trace_event *tevs,}for(i=0;i<ntevs;i++){-if(!tevs[i].point.address||tevs[i].point.retprobe)+if(!tevs[i].point.address)+continue;+if(tevs[i].point.retprobe&&!kretprobe_offset_is_supported())continue;/* If we found a wrong one, mark it by NULL symbol */if(kprobe_warn_out_range(tevs[i].point.symbol,
@@ -1528,11 +1530,6 @@ static int parse_perf_probe_point(char *arg, struct perf_probe_event *pev)return-EINVAL;}-if(pp->retprobe&&!pp->function){-semantic_error("Return probe requires an entry function.\n");-return-EINVAL;-}-if((pp->offset||pp->line||pp->lazy_line)&&pp->retprobe){semantic_error("Offset/Line/Lazy pattern can't be used with ""return probe.\n");
@@ -2841,7 +2838,8 @@ static int find_probe_trace_events_from_map(struct perf_probe_event *pev,}/* Note that the symbols in the kmodule are not relocated */-if(!pev->uprobes&&!pp->retprobe&&!pev->target){+if(!pev->uprobes&&!pev->target&&+(!pp->retprobe||kretprobe_offset_is_supported())){reloc_sym=kernel_get_ref_reloc_sym();if(!reloc_sym){pr_warning("Relocated base symbol is not found!\n");
On Sat, 4 Mar 2017 11:35:51 +0900
Masami Hiramatsu [off-list ref] wrote:
On Sat, 4 Mar 2017 09:49:11 +0900
Masami Hiramatsu [off-list ref] wrote:
quoted
On Thu, 2 Mar 2017 23:25:06 +0530
"Naveen N. Rao" [off-list ref] wrote:
quoted
We indicate support for accepting sym+offset with kretprobes through a
line in ftrace README. Parse the same to identify support and choose the
appropriate format for kprobe_events.
Could you give us an example of this change here? :)
for example, comment of commit 613f050d68a8 .
I think the code is OK, but we need actual example of result.
Hi Naveen,
I've tried following commands
$ grep "[Tt] user_read$" /proc/kallsyms
0000000000000000 T user_read
0000000000000000 t user_read
$ sudo ./perf probe -D user_read%return
r:probe/user_read _text+3539616
r:probe/user_read_1 _text+3653408
OK, looks good. However, when I set the retprobes, I got an error.
$ sudo ./perf probe -a user_read%return
Failed to write event: Invalid argument
Error: Failed to add events.
And kernel rejected that.
$ dmesg -k | tail -n 1
[ 850.315068] Given offset is not valid for return probe.
Hmm, curious..
I tried normal probes
$ sudo ./perf probe -D user_read
p:probe/user_read _text+3539616
p:probe/user_read_1 _text+3653408
$ sudo ./perf probe -a user_read
Added new events:
probe:user_read (on user_read)
probe:user_read_1 (on user_read)
You can now use it in all perf tools, such as:
perf record -e probe:user_read_1 -aR sleep 1
It works!
$ sudo ./perf probe -l
probe:user_read (on user_read@security/keys/user_defined.c)
probe:user_read_1 (on user_read@selinux/ss/policydb.c)
$ sudo cat /sys/kernel/debug/kprobes/list
ffffffff9237bf20 k user_read+0x0 [DISABLED][FTRACE]
ffffffff923602a0 k user_read+0x0 [DISABLED][FTRACE]
So, the both "_text+3539616" and "_text+3653408" are correctly located
on the entry address of user_read functions. It seems kernel-side
symbol+offset check is wrong.
FYI, without this patch, perf probe returns same place for same-name
functions. So this patch itself looks good.
$ sudo ./perf probe -D user_read%return
r:probe/user_read user_read+0
r:probe/user_read_1 user_read+0
Thanks,
--
Masami Hiramatsu [off-list ref]
On Sat, 4 Mar 2017 11:35:51 +0900
Masami Hiramatsu [off-list ref] wrote:
On Sat, 4 Mar 2017 09:49:11 +0900
Masami Hiramatsu [off-list ref] wrote:
quoted
On Thu, 2 Mar 2017 23:25:06 +0530
"Naveen N. Rao" [off-list ref] wrote:
quoted
We indicate support for accepting sym+offset with kretprobes through a
line in ftrace README. Parse the same to identify support and choose the
appropriate format for kprobe_events.
Could you give us an example of this change here? :)
for example, comment of commit 613f050d68a8 .
I think the code is OK, but we need actual example of result.
Hi Naveen,
I've tried following commands
$ grep "[Tt] user_read$" /proc/kallsyms
0000000000000000 T user_read
0000000000000000 t user_read
$ sudo ./perf probe -D user_read%return
r:probe/user_read _text+3539616
r:probe/user_read_1 _text+3653408
OK, looks good. However, when I set the retprobes, I got an error.
$ sudo ./perf probe -a user_read%return
Failed to write event: Invalid argument
Error: Failed to add events.
And kernel rejected that.
$ dmesg -k | tail -n 1
[ 850.315068] Given offset is not valid for return probe.
Hmm, curious..
Ah, I see.
static int create_trace_kprobe(int argc, char **argv)
...
} else {
/* a symbol specified */
symbol = argv[1];
/* TODO: support .init module functions */
ret = traceprobe_split_symbol_offset(symbol, &offset);
if (ret) {
pr_info("Failed to parse symbol.\n");
return ret;
}
if (offset && is_return &&
!arch_function_offset_within_entry(offset)) {
pr_info("Given offset is not valid for return probe.\n");
return -EINVAL;
}
}
So, actually, traceprobe_split_symbol_offset() just split out symbol
and offset from symbol string (e.g. "_text+3539616").
So, you should use kallsyms_lookup_size_offset() here again to check
offset.
Please try attached patch (I've already tested on x86-64).
$ sudo ./perf probe -a user_read%return
Added new events:
probe:user_read (on user_read%return)
probe:user_read_1 (on user_read%return)
You can now use it in all perf tools, such as:
perf record -e probe:user_read_1 -aR sleep 1
$ sudo ./perf probe -l
probe:user_read (on user_read%return@security/keys/user_defined.c)
probe:user_read_1 (on user_read%return@selinux/ss/policydb.c)
$ sudo cat /sys/kernel/debug/kprobes/list
ffffffff9637bf70 r user_read+0x0 [DISABLED][FTRACE]
ffffffff963602f0 r user_read+0x0 [DISABLED][FTRACE]
Thank you,
--
Masami Hiramatsu [off-list ref]
From: Naveen N. Rao <hidden> Date: 2017-03-06 15:05:38
On 2017/03/04 09:49AM, Masami Hiramatsu wrote:
On Thu, 2 Mar 2017 23:25:06 +0530
"Naveen N. Rao" [off-list ref] wrote:
quoted
We indicate support for accepting sym+offset with kretprobes through a
line in ftrace README. Parse the same to identify support and choose the
appropriate format for kprobe_events.
Could you give us an example of this change here? :)
for example, comment of commit 613f050d68a8 .
I think the code is OK, but we need actual example of result.
Sure :)
As an example, without this perf patch, but with the ftrace changes:
naveen@ubuntu:~/linux/tools/perf$ sudo cat /sys/kernel/debug/tracing/README | grep kretprobe
place (kretprobe): [<module>:]<symbol>[+<offset>]|<memaddr>
naveen@ubuntu:~/linux/tools/perf$
naveen@ubuntu:~/linux/tools/perf$ sudo ./perf probe -v do_open%return
probe-definition(0): do_open%return
symbol:do_open file:(null) line:0 offset:0 return:1 lazy:(null)
0 arguments
Looking at the vmlinux_path (8 entries long)
Using /boot/vmlinux for symbols
Open Debuginfo file: /boot/vmlinux
Try to find probe point from debuginfo.
Matched function: do_open [2d0c7d8]
Probe point found: do_open+0
Matched function: do_open [35d76b5]
found inline addr: 0xc0000000004ba984
Failed to find "do_open%return",
because do_open is an inlined function and has no return point.
An error occurred in debuginfo analysis (-22).
Trying to use symbols.
Opening /sys/kernel/debug/tracing//kprobe_events write=1
Writing event: r:probe/do_open do_open+0
Writing event: r:probe/do_open_1 do_open+0
Added new events:
probe:do_open (on do_open%return)
probe:do_open_1 (on do_open%return)
You can now use it in all perf tools, such as:
perf record -e probe:do_open_1 -aR sleep 1
naveen@ubuntu:~/linux/tools/perf$ sudo cat /sys/kernel/debug/kprobes/list
c000000000041370 k kretprobe_trampoline+0x0 [OPTIMIZED]
c0000000004433d0 r do_open+0x0 [DISABLED]
c0000000004433d0 r do_open+0x0 [DISABLED]
And after this patch (and the subsequent powerpc patch):
naveen@ubuntu:~/linux/tools/perf$ sudo ./perf probe -v do_open%return
probe-definition(0): do_open%return
symbol:do_open file:(null) line:0 offset:0 return:1 lazy:(null)
0 arguments
Looking at the vmlinux_path (8 entries long)
Using /boot/vmlinux for symbols
Open Debuginfo file: /boot/vmlinux
Try to find probe point from debuginfo.
Matched function: do_open [2d0c7d8]
Probe point found: do_open+0
Matched function: do_open [35d76b5]
found inline addr: 0xc0000000004ba984
Failed to find "do_open%return",
because do_open is an inlined function and has no return point.
An error occurred in debuginfo analysis (-22).
Trying to use symbols.
Opening /sys/kernel/debug/tracing//README write=0
Opening /sys/kernel/debug/tracing//kprobe_events write=1
Writing event: r:probe/do_open _text+4469712
Writing event: r:probe/do_open_1 _text+4956248
Added new events:
probe:do_open (on do_open%return)
probe:do_open_1 (on do_open%return)
You can now use it in all perf tools, such as:
perf record -e probe:do_open_1 -aR sleep 1
naveen@ubuntu:~/linux/tools/perf$ sudo cat /sys/kernel/debug/kprobes/list
c000000000041370 k kretprobe_trampoline+0x0 [OPTIMIZED]
c0000000004433d0 r do_open+0x0 [DISABLED]
c0000000004ba058 r do_open+0x8 [DISABLED]
Thanks,
- Naveen
From: Naveen N. Rao <hidden> Date: 2017-03-06 19:04:44
On 2017/03/04 01:34PM, Masami Hiramatsu wrote:
On Sat, 4 Mar 2017 11:35:51 +0900
Masami Hiramatsu [off-list ref] wrote:
quoted
On Sat, 4 Mar 2017 09:49:11 +0900
Masami Hiramatsu [off-list ref] wrote:
quoted
On Thu, 2 Mar 2017 23:25:06 +0530
"Naveen N. Rao" [off-list ref] wrote:
quoted
We indicate support for accepting sym+offset with kretprobes through a
line in ftrace README. Parse the same to identify support and choose the
appropriate format for kprobe_events.
Could you give us an example of this change here? :)
for example, comment of commit 613f050d68a8 .
I think the code is OK, but we need actual example of result.
Hi Naveen,
I've tried following commands
$ grep "[Tt] user_read$" /proc/kallsyms
0000000000000000 T user_read
0000000000000000 t user_read
$ sudo ./perf probe -D user_read%return
r:probe/user_read _text+3539616
r:probe/user_read_1 _text+3653408
OK, looks good. However, when I set the retprobes, I got an error.
$ sudo ./perf probe -a user_read%return
Failed to write event: Invalid argument
Error: Failed to add events.
And kernel rejected that.
$ dmesg -k | tail -n 1
[ 850.315068] Given offset is not valid for return probe.
Hmm, curious..
Ah, I see.
static int create_trace_kprobe(int argc, char **argv)
...
} else {
/* a symbol specified */
symbol = argv[1];
/* TODO: support .init module functions */
ret = traceprobe_split_symbol_offset(symbol, &offset);
if (ret) {
pr_info("Failed to parse symbol.\n");
return ret;
}
if (offset && is_return &&
!arch_function_offset_within_entry(offset)) {
pr_info("Given offset is not valid for return probe.\n");
return -EINVAL;
}
}
So, actually, traceprobe_split_symbol_offset() just split out symbol
and offset from symbol string (e.g. "_text+3539616").
So, you should use kallsyms_lookup_size_offset() here again to check
offset.
Ah, nice catch! I should have tested Steven's patch...
Please try attached patch (I've already tested on x86-64).
$ sudo ./perf probe -a user_read%return
Added new events:
probe:user_read (on user_read%return)
probe:user_read_1 (on user_read%return)
You can now use it in all perf tools, such as:
perf record -e probe:user_read_1 -aR sleep 1
$ sudo ./perf probe -l
probe:user_read (on user_read%return@security/keys/user_defined.c)
probe:user_read_1 (on user_read%return@selinux/ss/policydb.c)
$ sudo cat /sys/kernel/debug/kprobes/list
ffffffff9637bf70 r user_read+0x0 [DISABLED][FTRACE]
ffffffff963602f0 r user_read+0x0 [DISABLED][FTRACE]
On Mon, 6 Mar 2017 23:19:09 +0530
"Naveen N. Rao" [off-list ref] wrote:
Masami,
Your patch works, thanks! However, I felt we could refactor and reuse
some of the code across kprobes.c for this purpose. Can you please see
if the below patch is fine?
OK, looks good to me:)
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Thanks!
quoted hunk
Thanks,
Naveen
--
trace/kprobes: fix check for kretprobe offset within function entry
perf specifies an offset from _text and since this offset is fed
directly into the arch-specific helper, kprobes tracer rejects
installation of kretprobes through perf. Fix this by looking up the
actual offset from a function for the specified sym+offset.
Refactor and reuse existing routines to limit code duplication -- we
repurpose kprobe_addr() for determining final kprobe address and we
split out the function entry offset determination into a separate
generic helper.
Before patch:
naveen@ubuntu:~/linux/tools/perf$ sudo ./perf probe -v do_open%return
probe-definition(0): do_open%return
symbol:do_open file:(null) line:0 offset:0 return:1 lazy:(null)
0 arguments
Looking at the vmlinux_path (8 entries long)
Using /boot/vmlinux for symbols
Open Debuginfo file: /boot/vmlinux
Try to find probe point from debuginfo.
Matched function: do_open [2d0c7ff]
Probe point found: do_open+0
Matched function: do_open [35d76dc]
found inline addr: 0xc0000000004ba9c4
Failed to find "do_open%return",
because do_open is an inlined function and has no return point.
An error occurred in debuginfo analysis (-22).
Trying to use symbols.
Opening /sys/kernel/debug/tracing//README write=0
Opening /sys/kernel/debug/tracing//kprobe_events write=1
Writing event: r:probe/do_open _text+4469776
Failed to write event: Invalid argument
Error: Failed to add events. Reason: Invalid argument (Code: -22)
naveen@ubuntu:~/linux/tools/perf$ dmesg | tail
<snip>
[ 33.568656] Given offset is not valid for return probe.
After patch:
naveen@ubuntu:~/linux/tools/perf$ sudo ./perf probe -v do_open%return
probe-definition(0): do_open%return
symbol:do_open file:(null) line:0 offset:0 return:1 lazy:(null)
0 arguments
Looking at the vmlinux_path (8 entries long)
Using /boot/vmlinux for symbols
Open Debuginfo file: /boot/vmlinux
Try to find probe point from debuginfo.
Matched function: do_open [2d0c7d6]
Probe point found: do_open+0
Matched function: do_open [35d76b3]
found inline addr: 0xc0000000004ba9e4
Failed to find "do_open%return",
because do_open is an inlined function and has no return point.
An error occurred in debuginfo analysis (-22).
Trying to use symbols.
Opening /sys/kernel/debug/tracing//README write=0
Opening /sys/kernel/debug/tracing//kprobe_events write=1
Writing event: r:probe/do_open _text+4469808
Writing event: r:probe/do_open_1 _text+4956344
Added new events:
probe:do_open (on do_open%return)
probe:do_open_1 (on do_open%return)
You can now use it in all perf tools, such as:
perf record -e probe:do_open_1 -aR sleep 1
naveen@ubuntu:~/linux/tools/perf$ sudo cat /sys/kernel/debug/kprobes/list
c000000000041370 k kretprobe_trampoline+0x0 [OPTIMIZED]
c0000000004ba0b8 r do_open+0x8 [DISABLED]
c000000000443430 r do_open+0x0 [DISABLED]
Signed-off-by: Naveen N. Rao <redacted>
---
include/linux/kprobes.h | 1 +
kernel/kprobes.c | 40 ++++++++++++++++++++++++++--------------
kernel/trace/trace_kprobe.c | 2 +-
3 files changed, 28 insertions(+), 15 deletions(-)
@@ -695,7 +695,7 @@ static int create_trace_kprobe(int argc, char **argv)returnret;}if(offset&&is_return&&-!arch_function_offset_within_entry(offset)){+!function_offset_within_entry(NULL,symbol,offset)){pr_info("Given offset is not valid for return probe.\n");return-EINVAL;}
On Mon, 6 Mar 2017 20:34:10 +0530
"Naveen N. Rao" [off-list ref] wrote:
On 2017/03/04 09:49AM, Masami Hiramatsu wrote:
quoted
On Thu, 2 Mar 2017 23:25:06 +0530
"Naveen N. Rao" [off-list ref] wrote:
quoted
We indicate support for accepting sym+offset with kretprobes through a
line in ftrace README. Parse the same to identify support and choose the
appropriate format for kprobe_events.
Could you give us an example of this change here? :)
for example, comment of commit 613f050d68a8 .
I think the code is OK, but we need actual example of result.
Sure :)
As an example, without this perf patch, but with the ftrace changes:
naveen@ubuntu:~/linux/tools/perf$ sudo cat /sys/kernel/debug/tracing/README | grep kretprobe
place (kretprobe): [<module>:]<symbol>[+<offset>]|<memaddr>
naveen@ubuntu:~/linux/tools/perf$
naveen@ubuntu:~/linux/tools/perf$ sudo ./perf probe -v do_open%return
probe-definition(0): do_open%return
symbol:do_open file:(null) line:0 offset:0 return:1 lazy:(null)
0 arguments
Looking at the vmlinux_path (8 entries long)
Using /boot/vmlinux for symbols
Open Debuginfo file: /boot/vmlinux
Try to find probe point from debuginfo.
Matched function: do_open [2d0c7d8]
Probe point found: do_open+0
Matched function: do_open [35d76b5]
found inline addr: 0xc0000000004ba984
Failed to find "do_open%return",
because do_open is an inlined function and has no return point.
An error occurred in debuginfo analysis (-22).
Trying to use symbols.
Opening /sys/kernel/debug/tracing//kprobe_events write=1
Writing event: r:probe/do_open do_open+0
Writing event: r:probe/do_open_1 do_open+0
Added new events:
probe:do_open (on do_open%return)
probe:do_open_1 (on do_open%return)
You can now use it in all perf tools, such as:
perf record -e probe:do_open_1 -aR sleep 1
naveen@ubuntu:~/linux/tools/perf$ sudo cat /sys/kernel/debug/kprobes/list
c000000000041370 k kretprobe_trampoline+0x0 [OPTIMIZED]
c0000000004433d0 r do_open+0x0 [DISABLED]
c0000000004433d0 r do_open+0x0 [DISABLED]
And after this patch (and the subsequent powerpc patch):
naveen@ubuntu:~/linux/tools/perf$ sudo ./perf probe -v do_open%return
probe-definition(0): do_open%return
symbol:do_open file:(null) line:0 offset:0 return:1 lazy:(null)
0 arguments
Looking at the vmlinux_path (8 entries long)
Using /boot/vmlinux for symbols
Open Debuginfo file: /boot/vmlinux
Try to find probe point from debuginfo.
Matched function: do_open [2d0c7d8]
Probe point found: do_open+0
Matched function: do_open [35d76b5]
found inline addr: 0xc0000000004ba984
Failed to find "do_open%return",
because do_open is an inlined function and has no return point.
An error occurred in debuginfo analysis (-22).
Trying to use symbols.
Opening /sys/kernel/debug/tracing//README write=0
Opening /sys/kernel/debug/tracing//kprobe_events write=1
Writing event: r:probe/do_open _text+4469712
Writing event: r:probe/do_open_1 _text+4956248
Added new events:
probe:do_open (on do_open%return)
probe:do_open_1 (on do_open%return)
You can now use it in all perf tools, such as:
perf record -e probe:do_open_1 -aR sleep 1
naveen@ubuntu:~/linux/tools/perf$ sudo cat /sys/kernel/debug/kprobes/list
c000000000041370 k kretprobe_trampoline+0x0 [OPTIMIZED]
c0000000004433d0 r do_open+0x0 [DISABLED]
c0000000004ba058 r do_open+0x8 [DISABLED]
Ok, with this usage example.
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Thanks,
From: Naveen N. Rao <hidden> Date: 2017-03-07 00:49:34
Masami,
Your patch works, thanks! However, I felt we could refactor and reuse
some of the code across kprobes.c for this purpose. Can you please see
if the below patch is fine?
Thanks,
Naveen
--
trace/kprobes: fix check for kretprobe offset within function entry
perf specifies an offset from _text and since this offset is fed
directly into the arch-specific helper, kprobes tracer rejects
installation of kretprobes through perf. Fix this by looking up the
actual offset from a function for the specified sym+offset.
Refactor and reuse existing routines to limit code duplication -- we
repurpose kprobe_addr() for determining final kprobe address and we
split out the function entry offset determination into a separate
generic helper.
Before patch:
naveen@ubuntu:~/linux/tools/perf$ sudo ./perf probe -v do_open%return
probe-definition(0): do_open%return
symbol:do_open file:(null) line:0 offset:0 return:1 lazy:(null)
0 arguments
Looking at the vmlinux_path (8 entries long)
Using /boot/vmlinux for symbols
Open Debuginfo file: /boot/vmlinux
Try to find probe point from debuginfo.
Matched function: do_open [2d0c7ff]
Probe point found: do_open+0
Matched function: do_open [35d76dc]
found inline addr: 0xc0000000004ba9c4
Failed to find "do_open%return",
because do_open is an inlined function and has no return point.
An error occurred in debuginfo analysis (-22).
Trying to use symbols.
Opening /sys/kernel/debug/tracing//README write=0
Opening /sys/kernel/debug/tracing//kprobe_events write=1
Writing event: r:probe/do_open _text+4469776
Failed to write event: Invalid argument
Error: Failed to add events. Reason: Invalid argument (Code: -22)
naveen@ubuntu:~/linux/tools/perf$ dmesg | tail
<snip>
[ 33.568656] Given offset is not valid for return probe.
After patch:
naveen@ubuntu:~/linux/tools/perf$ sudo ./perf probe -v do_open%return
probe-definition(0): do_open%return
symbol:do_open file:(null) line:0 offset:0 return:1 lazy:(null)
0 arguments
Looking at the vmlinux_path (8 entries long)
Using /boot/vmlinux for symbols
Open Debuginfo file: /boot/vmlinux
Try to find probe point from debuginfo.
Matched function: do_open [2d0c7d6]
Probe point found: do_open+0
Matched function: do_open [35d76b3]
found inline addr: 0xc0000000004ba9e4
Failed to find "do_open%return",
because do_open is an inlined function and has no return point.
An error occurred in debuginfo analysis (-22).
Trying to use symbols.
Opening /sys/kernel/debug/tracing//README write=0
Opening /sys/kernel/debug/tracing//kprobe_events write=1
Writing event: r:probe/do_open _text+4469808
Writing event: r:probe/do_open_1 _text+4956344
Added new events:
probe:do_open (on do_open%return)
probe:do_open_1 (on do_open%return)
You can now use it in all perf tools, such as:
perf record -e probe:do_open_1 -aR sleep 1
naveen@ubuntu:~/linux/tools/perf$ sudo cat /sys/kernel/debug/kprobes/list
c000000000041370 k kretprobe_trampoline+0x0 [OPTIMIZED]
c0000000004ba0b8 r do_open+0x8 [DISABLED]
c000000000443430 r do_open+0x0 [DISABLED]
Signed-off-by: Naveen N. Rao <redacted>
---
include/linux/kprobes.h | 1 +
kernel/kprobes.c | 40 ++++++++++++++++++++++++++--------------
kernel/trace/trace_kprobe.c | 2 +-
3 files changed, 28 insertions(+), 15 deletions(-)
@@ -695,7 +695,7 @@ static int create_trace_kprobe(int argc, char **argv)returnret;}if(offset&&is_return&&-!arch_function_offset_within_entry(offset)){+!function_offset_within_entry(NULL,symbol,offset)){pr_info("Given offset is not valid for return probe.\n");return-EINVAL;}
From: Naveen N. Rao <hidden> Date: 2017-03-07 10:49:00
perf specifies an offset from _text and since this offset is fed
directly into the arch-specific helper, kprobes tracer rejects
installation of kretprobes through perf. Fix this by looking up the
actual offset from a function for the specified sym+offset.
Refactor and reuse existing routines to limit code duplication -- we
repurpose kprobe_addr() for determining final kprobe address and we
split out the function entry offset determination into a separate
generic helper.
Before patch:
naveen@ubuntu:~/linux/tools/perf$ sudo ./perf probe -v do_open%return
probe-definition(0): do_open%return
symbol:do_open file:(null) line:0 offset:0 return:1 lazy:(null)
0 arguments
Looking at the vmlinux_path (8 entries long)
Using /boot/vmlinux for symbols
Open Debuginfo file: /boot/vmlinux
Try to find probe point from debuginfo.
Matched function: do_open [2d0c7ff]
Probe point found: do_open+0
Matched function: do_open [35d76dc]
found inline addr: 0xc0000000004ba9c4
Failed to find "do_open%return",
because do_open is an inlined function and has no return point.
An error occurred in debuginfo analysis (-22).
Trying to use symbols.
Opening /sys/kernel/debug/tracing//README write=0
Opening /sys/kernel/debug/tracing//kprobe_events write=1
Writing event: r:probe/do_open _text+4469776
Failed to write event: Invalid argument
Error: Failed to add events. Reason: Invalid argument (Code: -22)
naveen@ubuntu:~/linux/tools/perf$ dmesg | tail
<snip>
[ 33.568656] Given offset is not valid for return probe.
After patch:
naveen@ubuntu:~/linux/tools/perf$ sudo ./perf probe -v do_open%return
probe-definition(0): do_open%return
symbol:do_open file:(null) line:0 offset:0 return:1 lazy:(null)
0 arguments
Looking at the vmlinux_path (8 entries long)
Using /boot/vmlinux for symbols
Open Debuginfo file: /boot/vmlinux
Try to find probe point from debuginfo.
Matched function: do_open [2d0c7d6]
Probe point found: do_open+0
Matched function: do_open [35d76b3]
found inline addr: 0xc0000000004ba9e4
Failed to find "do_open%return",
because do_open is an inlined function and has no return point.
An error occurred in debuginfo analysis (-22).
Trying to use symbols.
Opening /sys/kernel/debug/tracing//README write=0
Opening /sys/kernel/debug/tracing//kprobe_events write=1
Writing event: r:probe/do_open _text+4469808
Writing event: r:probe/do_open_1 _text+4956344
Added new events:
probe:do_open (on do_open%return)
probe:do_open_1 (on do_open%return)
You can now use it in all perf tools, such as:
perf record -e probe:do_open_1 -aR sleep 1
naveen@ubuntu:~/linux/tools/perf$ sudo cat /sys/kernel/debug/kprobes/list
c000000000041370 k kretprobe_trampoline+0x0 [OPTIMIZED]
c0000000004ba0b8 r do_open+0x8 [DISABLED]
c000000000443430 r do_open+0x0 [DISABLED]
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Naveen N. Rao <redacted>
---
include/linux/kprobes.h | 1 +
kernel/kprobes.c | 40 ++++++++++++++++++++++++++--------------
kernel/trace/trace_kprobe.c | 2 +-
3 files changed, 28 insertions(+), 15 deletions(-)
@@ -696,7 +696,7 @@ static int create_trace_kprobe(int argc, char **argv)returnret;}if(offset&&is_return&&-!arch_function_offset_within_entry(offset)){+!function_offset_within_entry(NULL,symbol,offset)){pr_info("Given offset is not valid for return probe.\n");return-EINVAL;}
From: Naveen N. Rao <hidden> Date: 2017-03-07 10:49:11
Simplify and separate out the ftrace README scanning logic into a
separate helper. This is used subsequently to scan for all patterns of
interest and to cache the result.
Since we are only interested in availability of probe argument type x,
we will only scan for that.
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Naveen N. Rao <redacted>
---
tools/perf/util/probe-file.c | 70 +++++++++++++++++++++++---------------------
1 file changed, 37 insertions(+), 33 deletions(-)
@@ -877,35 +877,31 @@ int probe_cache__show_all_caches(struct strfilter *filter)return0;}+enumftrace_readme{+FTRACE_README_PROBE_TYPE_X=0,+FTRACE_README_END,+};+staticstruct{constchar*pattern;-boolavail;-boolchecked;-}probe_type_table[]={-#define DEFINE_TYPE(idx, pat, def_avail) \-[idx]={.pattern=pat,.avail=(def_avail)}-DEFINE_TYPE(PROBE_TYPE_U,"* u8/16/32/64,*",true),-DEFINE_TYPE(PROBE_TYPE_S,"* s8/16/32/64,*",true),-DEFINE_TYPE(PROBE_TYPE_X,"* x8/16/32/64,*",false),-DEFINE_TYPE(PROBE_TYPE_STRING,"* string,*",true),-DEFINE_TYPE(PROBE_TYPE_BITFIELD,-"* b<bit-width>@<bit-offset>/<container-size>",true),+boolavail;+}ftrace_readme_table[]={+#define DEFINE_TYPE(idx, pat) \+[idx]={.pattern=pat,.avail=false}+DEFINE_TYPE(FTRACE_README_PROBE_TYPE_X,"*type: * x8/16/32/64,*"),};-boolprobe_type_is_available(enumprobe_typetype)+staticboolscan_ftrace_readme(enumftrace_readmetype){+intfd;FILE*fp;char*buf=NULL;size_tlen=0;-booltarget_line=false;-boolret=probe_type_table[type].avail;-intfd;+boolret=false;+staticboolscanned=false;-if(type>=PROBE_TYPE_END)-returnfalse;-/* We don't have to check the type which supported by default */-if(ret||probe_type_table[type].checked)-returnret;+if(scanned)+gotoresult;fd=open_trace_file("README",false);if(fd<0)
@@ -917,21 +913,29 @@ bool probe_type_is_available(enum probe_type type)returnret;}-while(getline(&buf,&len,fp)>0&&!ret){-if(!target_line){-target_line=!!strstr(buf," type: ");-if(!target_line)-continue;-}elseif(strstr(buf,"\t ")!=buf)-break;-ret=strglobmatch(buf,probe_type_table[type].pattern);-}-/* Cache the result */-probe_type_table[type].checked=true;-probe_type_table[type].avail=ret;+while(getline(&buf,&len,fp)>0)+for(enumftrace_readmei=0;i<FTRACE_README_END;i++)+if(!ftrace_readme_table[i].avail)+ftrace_readme_table[i].avail=+strglobmatch(buf,ftrace_readme_table[i].pattern);+scanned=true;fclose(fp);free(buf);-returnret;+result:+if(type>=FTRACE_README_END)+returnfalse;++returnftrace_readme_table[type].avail;+}++boolprobe_type_is_available(enumprobe_typetype)+{+if(type>=PROBE_TYPE_END)+returnfalse;+elseif(type==PROBE_TYPE_X)+returnscan_ftrace_readme(FTRACE_README_PROBE_TYPE_X);++returntrue;}
From: Naveen N. Rao <hidden> Date: 2017-03-07 10:49:24
We indicate support for accepting sym+offset with kretprobes through a
line in ftrace README. Parse the same to identify support and choose the
appropriate format for kprobe_events.
As an example, without this perf patch, but with the ftrace changes:
naveen@ubuntu:~/linux/tools/perf$ sudo cat /sys/kernel/debug/tracing/README | grep kretprobe
place (kretprobe): [<module>:]<symbol>[+<offset>]|<memaddr>
naveen@ubuntu:~/linux/tools/perf$
naveen@ubuntu:~/linux/tools/perf$ sudo ./perf probe -v do_open%return
probe-definition(0): do_open%return
symbol:do_open file:(null) line:0 offset:0 return:1 lazy:(null)
0 arguments
Looking at the vmlinux_path (8 entries long)
Using /boot/vmlinux for symbols
Open Debuginfo file: /boot/vmlinux
Try to find probe point from debuginfo.
Matched function: do_open [2d0c7d8]
Probe point found: do_open+0
Matched function: do_open [35d76b5]
found inline addr: 0xc0000000004ba984
Failed to find "do_open%return",
because do_open is an inlined function and has no return point.
An error occurred in debuginfo analysis (-22).
Trying to use symbols.
Opening /sys/kernel/debug/tracing//kprobe_events write=1
Writing event: r:probe/do_open do_open+0
Writing event: r:probe/do_open_1 do_open+0
Added new events:
probe:do_open (on do_open%return)
probe:do_open_1 (on do_open%return)
You can now use it in all perf tools, such as:
perf record -e probe:do_open_1 -aR sleep 1
naveen@ubuntu:~/linux/tools/perf$ sudo cat /sys/kernel/debug/kprobes/list
c000000000041370 k kretprobe_trampoline+0x0 [OPTIMIZED]
c0000000004433d0 r do_open+0x0 [DISABLED]
c0000000004433d0 r do_open+0x0 [DISABLED]
And after this patch (and the subsequent powerpc patch):
naveen@ubuntu:~/linux/tools/perf$ sudo ./perf probe -v do_open%return
probe-definition(0): do_open%return
symbol:do_open file:(null) line:0 offset:0 return:1 lazy:(null)
0 arguments
Looking at the vmlinux_path (8 entries long)
Using /boot/vmlinux for symbols
Open Debuginfo file: /boot/vmlinux
Try to find probe point from debuginfo.
Matched function: do_open [2d0c7d8]
Probe point found: do_open+0
Matched function: do_open [35d76b5]
found inline addr: 0xc0000000004ba984
Failed to find "do_open%return",
because do_open is an inlined function and has no return point.
An error occurred in debuginfo analysis (-22).
Trying to use symbols.
Opening /sys/kernel/debug/tracing//README write=0
Opening /sys/kernel/debug/tracing//kprobe_events write=1
Writing event: r:probe/do_open _text+4469712
Writing event: r:probe/do_open_1 _text+4956248
Added new events:
probe:do_open (on do_open%return)
probe:do_open_1 (on do_open%return)
You can now use it in all perf tools, such as:
perf record -e probe:do_open_1 -aR sleep 1
naveen@ubuntu:~/linux/tools/perf$ sudo cat /sys/kernel/debug/kprobes/list
c000000000041370 k kretprobe_trampoline+0x0 [OPTIMIZED]
c0000000004433d0 r do_open+0x0 [DISABLED]
c0000000004ba058 r do_open+0x8 [DISABLED]
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Naveen N. Rao <redacted>
---
tools/perf/util/probe-event.c | 12 +++++-------
tools/perf/util/probe-file.c | 7 +++++++
tools/perf/util/probe-file.h | 1 +
3 files changed, 13 insertions(+), 7 deletions(-)
@@ -757,7 +757,9 @@ post_process_kernel_probe_trace_events(struct probe_trace_event *tevs,}for(i=0;i<ntevs;i++){-if(!tevs[i].point.address||tevs[i].point.retprobe)+if(!tevs[i].point.address)+continue;+if(tevs[i].point.retprobe&&!kretprobe_offset_is_supported())continue;/* If we found a wrong one, mark it by NULL symbol */if(kprobe_warn_out_range(tevs[i].point.symbol,
@@ -1528,11 +1530,6 @@ static int parse_perf_probe_point(char *arg, struct perf_probe_event *pev)return-EINVAL;}-if(pp->retprobe&&!pp->function){-semantic_error("Return probe requires an entry function.\n");-return-EINVAL;-}-if((pp->offset||pp->line||pp->lazy_line)&&pp->retprobe){semantic_error("Offset/Line/Lazy pattern can't be used with ""return probe.\n");
@@ -2841,7 +2838,8 @@ static int find_probe_trace_events_from_map(struct perf_probe_event *pev,}/* Note that the symbols in the kmodule are not relocated */-if(!pev->uprobes&&!pp->retprobe&&!pev->target){+if(!pev->uprobes&&!pev->target&&+(!pp->retprobe||kretprobe_offset_is_supported())){reloc_sym=kernel_get_ref_reloc_sym();if(!reloc_sym){pr_warning("Relocated base symbol is not found!\n");
From: Naveen N. Rao <hidden> Date: 2017-03-07 10:50:02
perf now uses an offset from _text/_stext for kretprobes if the kernel
supports it, rather than the actual function name. As such, let's choose
the LEP for powerpc ABIv2 so as to ensure the probe gets hit. Do it only
if the kernel supports specifying offsets with kretprobes.
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Naveen N. Rao <redacted>
---
tools/perf/arch/powerpc/util/sym-handling.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
@@ -79,11 +80,12 @@ void arch__fix_tev_from_maps(struct perf_probe_event *pev,*However,iftheuserspecifiesanoffset,wefallbacktousingthe*GEPsincealluserspaceapplications(objdump/readelf)showfunction*disassemblywithoffsetsfromtheGEP.-*-*Inaddition,weshouldn'tspecifyanoffsetforkretprobes.*/-if(pev->point.offset||(!pev->uprobes&&pev->point.retprobe)||-!map||!sym)+if(pev->point.offset||!map||!sym)+return;++/* For kretprobes, add an offset only if the kernel supports it */+if(!pev->uprobes&&pev->point.retprobe&&!kretprobe_offset_is_supported())return;lep_offset=PPC64_LOCAL_ENTRY_OFFSET(sym->arch_sym);
From: Naveen N. Rao <hidden> Date: 2017-03-07 10:50:07
On 2017/03/06 10:06PM, Masami Hiramatsu wrote:
On Mon, 6 Mar 2017 23:19:09 +0530
"Naveen N. Rao" [off-list ref] wrote:
quoted
Masami,
Your patch works, thanks! However, I felt we could refactor and reuse
some of the code across kprobes.c for this purpose. Can you please see
if the below patch is fine?
OK, looks good to me:)
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Thanks for the review, Masami!
I ended up adding one more patch to this series (patch 5/6) to move the
ftrace README scanning out of probe-file.c, as it doesn't need libelf.
Patch 6 fails to build without libelf otherwise. Please take a look.
Arnaldo,
I am re-sending the remaining patches in this series which apply on top
of the 4 patches you sent to Ingo, so as to keep this simple. All the
patches have been acked, except the new patch 5/6. Kindly take a look.
Thanks,
Naveen
--
Naveen N. Rao (6):
trace/kprobes: fix check for kretprobe offset within function entry
powerpc: kretprobes: override default function entry offset
perf: probe: factor out the ftrace README scanning
perf: kretprobes: offset from reloc_sym if kernel supports it
perf: probes: move ftrace README parsing logic into
trace-event-parse.c
perf: powerpc: choose local entry point with kretprobes
arch/powerpc/kernel/kprobes.c | 9 +++
include/linux/kprobes.h | 1 +
kernel/kprobes.c | 40 ++++++++-----
kernel/trace/trace_kprobe.c | 2 +-
tools/perf/arch/powerpc/util/sym-handling.c | 10 ++--
tools/perf/util/probe-event.c | 12 ++--
tools/perf/util/probe-file.c | 80 +++-----------------------
tools/perf/util/probe-file.h | 1 -
tools/perf/util/trace-event-parse.c | 89 +++++++++++++++++++++++++++++
tools/perf/util/trace-event.h | 4 ++
10 files changed, 149 insertions(+), 99 deletions(-)
--
2.11.1
From: Naveen N. Rao <hidden> Date: 2017-03-07 10:50:30
With ABIv2, we offset 8 bytes into a function to get at the local entry
point.
Acked-by: Ananth N Mavinakayanahalli <redacted>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Naveen N. Rao <redacted>
---
arch/powerpc/kernel/kprobes.c | 9 +++++++++
1 file changed, 9 insertions(+)
On Tue, 7 Mar 2017 16:17:40 +0530
"Naveen N. Rao" [off-list ref] wrote:
probe-file.c needs libelf, but scanning ftrace README does not require
that. As such, move the ftrace README scanning logic out of probe-file.c
and into trace-event-parse.c.
As far as I can see, there is no reason to push this out from probe-file.c
because anyway this API using code requires libelf. Without this, I can
still build perf with NO_LIBELF=1. So I wouldn't like to pick this.
(I think we can drop this from this series)
Thank you,
From: Naveen N. Rao <hidden> Date: 2017-03-07 16:39:18
On 2017/03/07 03:03PM, Masami Hiramatsu wrote:
On Tue, 7 Mar 2017 16:17:40 +0530
"Naveen N. Rao" [off-list ref] wrote:
quoted
probe-file.c needs libelf, but scanning ftrace README does not require
that. As such, move the ftrace README scanning logic out of probe-file.c
and into trace-event-parse.c.
Hmm, it seems probe-file.c doesn't require libelf at all...
I would like to keep ftrace related things in probe-file.c.
Not sure I understand. probe-file.h explicitly calls out a need for
libelf due to the probe cache and related routines - commit
40218daea1db1 ("perf list: Show SDT and pre-cached events").
However, if you prefer to retain the ftrace README scanning here, we can
drop this patch and I can update patch 6 to check for libelf.
Thanks,
Naveen
On Tue, 7 Mar 2017 16:17:40 +0530
"Naveen N. Rao" [off-list ref] wrote:
probe-file.c needs libelf, but scanning ftrace README does not require
that. As such, move the ftrace README scanning logic out of probe-file.c
and into trace-event-parse.c.
Hmm, it seems probe-file.c doesn't require libelf at all...
I would like to keep ftrace related things in probe-file.c.
Thanks,
From: Naveen N. Rao <hidden> Date: 2017-03-07 19:44:24
On 2017/03/07 04:51PM, Masami Hiramatsu wrote:
On Tue, 7 Mar 2017 16:17:40 +0530
"Naveen N. Rao" [off-list ref] wrote:
quoted
probe-file.c needs libelf, but scanning ftrace README does not require
that. As such, move the ftrace README scanning logic out of probe-file.c
and into trace-event-parse.c.
As far as I can see, there is no reason to push this out from probe-file.c
because anyway this API using code requires libelf. Without this, I can
still build perf with NO_LIBELF=1. So I wouldn't like to pick this.
(I think we can drop this from this series)
Ok. We can drop this. I'll rework patch 6/6.
Thanks,
Naveen
From: Naveen N. Rao <hidden> Date: 2017-03-07 20:51:08
perf now uses an offset from _text/_stext for kretprobes if the kernel
supports it, rather than the actual function name. As such, let's choose
the LEP for powerpc ABIv2 so as to ensure the probe gets hit. Do it only
if the kernel supports specifying offsets with kretprobes.
Signed-off-by: Naveen N. Rao <redacted>
---
Changes:
- updated to address build issues due to dropping patch 5/6.
tools/perf/arch/powerpc/util/sym-handling.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
@@ -79,11 +80,16 @@ void arch__fix_tev_from_maps(struct perf_probe_event *pev,*However,iftheuserspecifiesanoffset,wefallbacktousingthe*GEPsincealluserspaceapplications(objdump/readelf)showfunction*disassemblywithoffsetsfromtheGEP.-*-*Inaddition,weshouldn'tspecifyanoffsetforkretprobes.*/-if(pev->point.offset||(!pev->uprobes&&pev->point.retprobe)||-!map||!sym)+if(pev->point.offset||!map||!sym)+return;++/* For kretprobes, add an offset only if the kernel supports it */+if(!pev->uprobes&&pev->point.retprobe+#ifdef HAVE_LIBELF_SUPPORT+&&!kretprobe_offset_is_supported()+#endif+)return;lep_offset=PPC64_LOCAL_ENTRY_OFFSET(sym->arch_sym);
From: Steven Rostedt <rostedt@goodmis.org> Date: 2017-03-07 21:41:22
FYI,
When creating new patch series, please start a new thread, and don't
post a patch as a reply to another patch. It gets easily lost that way.
-- Steve
On Thu, 2 Mar 2017 23:25:05 +0530
"Naveen N. Rao" [off-list ref] wrote:
Simplify and separate out the ftrace README scanning logic into a
separate helper. This is used subsequently to scan for all patterns of
interest and to cache the result.
Since we are only interested in availability of probe argument type x,
we will only scan for that.
Signed-off-by: Naveen N. Rao <redacted>
---
From: Steven Rostedt <rostedt@goodmis.org> Date: 2017-03-07 21:41:35
Please start a new thread. When sending patches as replies to other
patch threads, especially this deep into the thread, they will most
likely get ignored.
-- Steve
From: Naveen N. Rao <hidden> Date: 2017-03-08 10:45:23
On 2017/03/07 03:47PM, Steven Rostedt wrote:
Please start a new thread. When sending patches as replies to other
patch threads, especially this deep into the thread, they will most
likely get ignored.
Sorry, got carried off. I will re-post in a new series.
- Naveen