RE: [PATCH v11 8/9] arm64: Add kernel return probes support (kretprobes)

Hi, >From: Sandeepa Prabhu > >The pre-handler of this special 'trampoline' kprobe executes the return >probe handler functions and restores original return address in ELR_EL1. >This way the saved pt_regs still hold the original register context to be >carried back to

RE: [PATCH v11 8/9] arm64: Add kernel return probes support (kretprobes)

Hi, >From: Sandeepa Prabhu > >The pre-handler of this special 'trampoline' kprobe executes the return >probe handler functions and restores original return address in ELR_EL1. >This way the saved pt_regs still hold the original register context to be >carried back to the probed kernel function.

RE: [PATCH v11 8/9] arm64: Add kernel return probes support (kretprobes)

>From: 平松雅巳 / HIRAMATU，MASAMI [mailto:masami.hiramatsu...@hitachi.com] > >Hi, > >>From: Sandeepa Prabhu <sandeepa.s.pra...@gmail.com> >> >>The pre-handler of this special 'trampoline' kprobe executes the return >>probe handler functions and restores orig

RE: [PATCH v11 8/9] arm64: Add kernel return probes support (kretprobes)

>From: 平松雅巳 / HIRAMATU，MASAMI [mailto:masami.hiramatsu...@hitachi.com] > >Hi, > >>From: Sandeepa Prabhu >> >>The pre-handler of this special 'trampoline' kprobe executes the return >>probe handler functions and restores original return address in ELR_EL1. >

RE: [PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist

>From: "David A. Long" > >Currrently taking exceptions when accessing user data from a kprobe'd >instruction doesn't work. Avoid this situation by blacklisting the relevant >functions. > >Signed-off-by: David A. Long Looks good to me. Reviewed-by:

RE: [PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist

>From: "David A. Long" > >Currrently taking exceptions when accessing user data from a kprobe'd >instruction doesn't work. Avoid this situation by blacklisting the relevant >functions. > >Signed-off-by: David A. Long Looks good to me. Reviewed-by: Masami Hiramatsu Thanks, >--- >

RE: [PATCH v10 1/9] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature

>From: "David A. Long" > >Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64. > >Signed-off-by: David A. Long Looks good for me. Reviewed-by: Masami Hiramatsu Thanks, >--- > arch/arm64/Kconfig | 1

RE: [PATCH v10 1/9] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature

>From: "David A. Long" > >Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64. > >Signed-off-by: David A. Long Looks good for me. Reviewed-by: Masami Hiramatsu Thanks, >--- > arch/arm64/Kconfig | 1 + > arch/arm64/include/asm/ptrace.h | 31 +++ >

RE: [PATCH v10 0/9] arm64: Add kernel probes (kprobes) support

Hi David, Thank you for updating the series. I'll review it this week. Just one comment on __kprobes. Nowadays kprobes already using NOKPROBE_SYMBOL() instead of that, since __kprobes moves all functions into another section and will mess up symbol table. In asm code, maybe you can reuse

RE: [PATCH v10 0/9] arm64: Add kernel probes (kprobes) support

Hi David, Thank you for updating the series. I'll review it this week. Just one comment on __kprobes. Nowadays kprobes already using NOKPROBE_SYMBOL() instead of that, since __kprobes moves all functions into another section and will mess up symbol table. In asm code, maybe you can reuse

RE: [RFC] perf: probe_finder: continue if atleast one probe point found

BTW, ./perf probe \ -k ./vmlinux -s ./ -x /lib/x86_64-linux-gnu/libc.so.6 -a 'malloc $params' might help your case. $params is expanded to function parameters automatically and if there is no parameters, it is just ignored :) Thank you, >From: 平松雅巳 / HIRAMATU，MASAMI [mailto:masami.hirama

RE: [RFC] perf: probe_finder: continue if atleast one probe point found

BTW, ./perf probe \ -k ./vmlinux -s ./ -x /lib/x86_64-linux-gnu/libc.so.6 -a 'malloc $params' might help your case. $params is expanded to function parameters automatically and if there is no parameters, it is just ignored :) Thank you, >From: 平松雅巳 / HIRAMATU，MASAMI [mailto:masami.hirama

RE: [RFC] perf: probe_finder: continue if atleast one probe point found

Hi, >From: Arnaldo Carvalho de Melo [mailto:a...@kernel.org] > >Em Sun, Feb 28, 2016 at 03:49:44AM -0800, Joel Fernandes escreveu: >> Taeung, >> >> Thanks for that. As this is an RFC, I have added them now to this email >> thread and when I post the final patch, I'll include them in CC. >> >>

RE: [RFC] perf: probe_finder: continue if atleast one probe point found

Hi, >From: Arnaldo Carvalho de Melo [mailto:a...@kernel.org] > >Em Sun, Feb 28, 2016 at 03:49:44AM -0800, Joel Fernandes escreveu: >> Taeung, >> >> Thanks for that. As this is an RFC, I have added them now to this email >> thread and when I post the final patch, I'll include them in CC. >> >>

RE: [PATCH v14 01/22] tracing: Update some tracing_map constants and comments

Hi Tom, From: Tom Zanussi [mailto:tom.zanu...@linux.intel.com] > >Make it clear exactly how many keys and values are supported through >better defines, and add 1 to the vals count, since normally clients >want support for at least a hitcount and two other values. OK, but would that (increment

RE: [PATCH v14 01/22] tracing: Update some tracing_map constants and comments

Hi Tom, From: Tom Zanussi [mailto:tom.zanu...@linux.intel.com] > >Make it clear exactly how many keys and values are supported through >better defines, and add 1 to the vals count, since normally clients >want support for at least a hitcount and two other values. OK, but would that (increment

RE: [RFC v2 7/7] kprobes: port to linker table

>From: Luis R. Rodriguez [mailto:mcg...@kernel.org] > >kprobe makes use of two custom sections: > >type name beginend >init.data _kprobe_blacklist __start_kprobe_blacklist __stop_kprobe_blacklist >text .kprobes.text __kprobes_text_start

RE: [RFC v2 7/7] kprobes: port to linker table

>From: Luis R. Rodriguez [mailto:mcg...@kernel.org] > >kprobe makes use of two custom sections: > >type name beginend >init.data _kprobe_blacklist __start_kprobe_blacklist __stop_kprobe_blacklist >text .kprobes.text __kprobes_text_start

RE: [PATCH 00/29] tracing: 'hist' triggers

Hi Tom, Just a note that I've tested by my test scripts. I'll try to add a test case for Namhyung's extension. Thanks, >From: Tom Zanussi [mailto:tom.zanu...@linux.intel.com] >On Fri, 2016-02-12 at 11:59 -0500, Steven Rostedt wrote: >> On Fri, 12 Feb 2016 10:17:37 -0600 >> Tom Zanussi

RE: [PATCH 00/29] tracing: 'hist' triggers

Hi Tom, Just a note that I've tested by my test scripts. I'll try to add a test case for Namhyung's extension. Thanks, >From: Tom Zanussi [mailto:tom.zanu...@linux.intel.com] >On Fri, 2016-02-12 at 11:59 -0500, Steven Rostedt wrote: >> On Fri, 12 Feb 2016 10:17:37 -0600 >> Tom Zanussi wrote:

RE: [PATCH 0/3] module stable fixes.

ch & Development Group E-mail: masami.hiramatsu...@hitachi.com >-Original Message- >From: Rusty Russell [mailto:ru...@rustcorp.com.au] >Sent: Friday, February 05, 2016 9:14 AM >To: linux-kernel@vger.kernel.org >Cc: Rusty Russell; Weilong Chen; 平松雅巳 / HIRAMATU，MASAM

RE: [PATCH 2/3] module: wrapper for symbol name.

From: Rusty Russell [mailto:ru...@rustcorp.com.au] > >This trivial wrapper adds clarity and makes the following patch >smaller. > >Cc: sta...@kernel.org >Signed-off-by: Rusty Russell Looks good to me. Reviewed-by: Masami Hiramatsu Thanks! >--- > kernel/module.c | 26

RE: [PATCH 3/3] modules: fix longstanding /proc/kallsyms vs module insertion race.

From: Rusty Russell [mailto:ru...@rustcorp.com.au] > >For CONFIG_KALLSYMS, we keep two symbol tables and two string tables. >There's one full copy, marked SHF_ALLOC and laid out at the end of the >module's init section. There's also a cut-down version that only >contains core symbols and strings,

RE: [PATCH RESEND] kprobe: Use percpu counter to collect nhit statistics

From: Martin KaFai Lau [mailto:ka...@fb.com] > >When doing ebpf+kprobe on some hot TCP functions (e.g. >tcp_rcv_established), the kprobe_dispatcher shows up in 'perf report'. > >In kprobe_dispatcher(), there is a lot of cache bouncing >in 'tk->nhit++'. 'tk->nhit' and 'tk->tp.flags' also share

RE: [PATCH RESEND] kprobe: Use percpu counter to collect nhit statistics

From: Martin KaFai Lau [mailto:ka...@fb.com] > >When doing ebpf+kprobe on some hot TCP functions (e.g. >tcp_rcv_established), the kprobe_dispatcher shows up in 'perf report'. > >In kprobe_dispatcher(), there is a lot of cache bouncing >in 'tk->nhit++'. 'tk->nhit' and 'tk->tp.flags' also share

RE: [PATCH 0/3] module stable fixes.

>Sent: Friday, February 05, 2016 9:14 AM >To: linux-kernel@vger.kernel.org >Cc: Rusty Russell; Weilong Chen; 平松雅巳 / HIRAMATU，MASAMI; Peter Zijlstra >Subject: [PATCH 0/3] module stable fixes. > >Luis' async_probe is a recent issue, but the /proc/kallsyms vs >module insertion race h

RE: [PATCH 3/3] modules: fix longstanding /proc/kallsyms vs module insertion race.

From: Rusty Russell [mailto:ru...@rustcorp.com.au] > >For CONFIG_KALLSYMS, we keep two symbol tables and two string tables. >There's one full copy, marked SHF_ALLOC and laid out at the end of the >module's init section. There's also a cut-down version that only >contains core symbols and strings,

RE: [PATCH 2/3] module: wrapper for symbol name.

From: Rusty Russell [mailto:ru...@rustcorp.com.au] > >This trivial wrapper adds clarity and makes the following patch >smaller. > >Cc: sta...@kernel.org >Signed-off-by: Rusty Russell Looks good to me. Reviewed-by: Masami Hiramatsu

RE: [PATCH perf 3/4] perf tools: Fix unused variables: x86_{32,64}_regoffset_table

>From: Wangnan (F) [mailto:wangn...@huawei.com] >On 2016/1/22 13:56, 平松雅巳 / HIRAMATU，MASAMI wrote: >>> From: Wangnan (F) [mailto:wangn...@huawei.com] >>> I think this problem is not introduced by my patch. In fact >>> there's a fundamental problem in get_arch_r

RE: [PATCH perf 3/4] perf tools: Fix unused variables: x86_{32,64}_regoffset_table

>From: Wangnan (F) [mailto:wangn...@huawei.com] >On 2016/1/22 13:56, 平松雅巳 / HIRAMATU，MASAMI wrote: >>> From: Wangnan (F) [mailto:wangn...@huawei.com] >>> I think this problem is not introduced by my patch. In fact >>> there's a fundamental problem in get_arch_r

RE: [PATCH perf 3/4] perf tools: Fix unused variables: x86_{32,64}_regoffset_table

>From: Wangnan (F) [mailto:wangn...@huawei.com] > >On 2016/1/20 21:59, Arnaldo Carvalho de Melo wrote: >> Em Tue, Jan 19, 2016 at 09:33:06PM +, Ben Hutchings escreveu: >>> gcc 5 doesn't seem to care about these, but gcc 6 does and that >>> results in a build failure. >> Ben, please CC the

RE: [PATCH 24/33] x86/kprobes: Get rid of kretprobe_trampoline_holder()

>From: Josh Poimboeuf [mailto:jpoim...@redhat.com] > >The kretprobe_trampoline_holder() wrapper around kretprobe_trampoline() >isn't used anywhere and adds some unnecessary frame pointer instructions >which never execute. Instead, just make kretprobe_trampoline() a proper >ELF function. > Looks

RE: [PATCH 24/33] x86/kprobes: Get rid of kretprobe_trampoline_holder()

>From: Josh Poimboeuf [mailto:jpoim...@redhat.com] > >The kretprobe_trampoline_holder() wrapper around kretprobe_trampoline() >isn't used anywhere and adds some unnecessary frame pointer instructions >which never execute. Instead, just make kretprobe_trampoline() a proper >ELF function. > Looks

RE: [PATCH perf 3/4] perf tools: Fix unused variables: x86_{32,64}_regoffset_table

>From: Wangnan (F) [mailto:wangn...@huawei.com] > >On 2016/1/20 21:59, Arnaldo Carvalho de Melo wrote: >> Em Tue, Jan 19, 2016 at 09:33:06PM +, Ben Hutchings escreveu: >>> gcc 5 doesn't seem to care about these, but gcc 6 does and that >>> results in a build failure. >> Ben, please CC the

RE: [PATCH perf/core 00/22] perf refcnt debugger API and fixes

From: Wangnan (F) [mailto:wangn...@huawei.com] > > >On 2015/12/11 10:15, 平松雅巳 / HIRAMATU，MASAMI wrote: >> From: 'Arnaldo Carvalho de Melo' [mailto:a...@kernel.org] >>> But this requires having these special refcnt__ routines, that will make >>> tools/perf/ code p

RE: [PATCH perf/core 00/22] perf refcnt debugger API and fixes

From: 'Arnaldo Carvalho de Melo' [mailto:a...@kernel.org] > >But this requires having these special refcnt__ routines, that will make >tools/perf/ code patterns for reference counts look different that the >refcount patterns in the kernel :-\ BTW, I think even without the refcnt debugger, we'd

RE: [PATCH perf/core 00/22] perf refcnt debugger API and fixes

From: Wangnan (F) [mailto:wangn...@huawei.com] >On 2015/12/10 23:12, 'Arnaldo Carvalho de Melo' wrote: > >[SNIP] >> But this requires having these special refcnt__ routines, that will make >> tools/perf/ code patterns for reference counts look different that the >> refcount patterns in the kernel

RE: [PATCH perf/core 00/22] perf refcnt debugger API and fixes

>From: Arnaldo Carvalho de Melo [mailto:a...@kernel.org] > >Em Wed, Dec 09, 2015 at 11:10:48AM +0900, Masami Hiramatsu escreveu: >> Hi Arnaldo, >> >> Here is a series of patches for perf refcnt debugger and >> some fixes. >> >> In this series I've replaced all atomic reference counters >> with the

RE: [PATCH 2/2 (v2)] perf tools: Prevent calling machine__delete() on non-allocated machine

Hi Wang, >From: Wang Nan [mailto:wangn...@huawei.com] > >To prevent futher commits calling machine__delete() on non-allocated >'struct machine' (which would cause memory corruption), this patch >enforces machine__init(), record whether a machine structure is >dynamically allocated or not, and

RE: [PATCH perf/core 16/22] perf: Fix __cmd_top and perf_session__process_events to put the idle thread

>From: Arnaldo Carvalho de Melo [mailto:a...@kernel.org] > >Em Wed, Dec 09, 2015 at 11:11:23AM +0900, Masami Hiramatsu escreveu: >> Since perf_session__register_idle_thread() got the idle thread, >> caller functions have to put it afterwards. >> Note that since the thread was already inserted to

RE: [PATCH/RFC 01/16] perf top: Delete half-processed hist entries when exit

>From: Namhyung Kim [mailto:namhy...@kernel.org] > >After sample processing is done, hist entries are in both of >hists->entries and hists->entries_in (or hists->entries_collapsed). >So I guess perf report does not have leaks on hists. > >But for perf top, it's possible to have half-processed

RE: [PATCH perf/core 14/22] perf: Fix dso__load_sym to put dso

From: Arnaldo Carvalho de Melo [mailto:a...@kernel.org] > >Em Wed, Dec 09, 2015 at 11:11:18AM +0900, Masami Hiramatsu escreveu: >> +++ b/tools/perf/util/symbol-elf.c >> @@ -1045,6 +1045,8 @@ int dso__load_sym(struct dso *dso, struct map *map, >> /* kmaps already got it

RE: [PATCH perf/core 00/22] perf refcnt debugger API and fixes

>From: Namhyung Kim [mailto:namhy...@kernel.org] > >Hi Arnaldo and Masami, > >On Wed, Dec 09, 2015 at 10:41:38AM -0300, Arnaldo Carvalho de Melo wrote: >> Em Wed, Dec 09, 2015 at 11:10:48AM +0900, Masami Hiramatsu escreveu: >> > In this series I've also tried to fix some object leaks in perf top

RE: [PATCH perf/core 14/22] perf: Fix dso__load_sym to put dso

From: Arnaldo Carvalho de Melo [mailto:a...@kernel.org] > >Em Wed, Dec 09, 2015 at 11:11:18AM +0900, Masami Hiramatsu escreveu: >> +++ b/tools/perf/util/symbol-elf.c >> @@ -1045,6 +1045,8 @@ int dso__load_sym(struct dso *dso, struct map *map, >> /* kmaps already got it

RE: [PATCH perf/core 00/22] perf refcnt debugger API and fixes

>From: Namhyung Kim [mailto:namhy...@kernel.org] > >Hi Arnaldo and Masami, > >On Wed, Dec 09, 2015 at 10:41:38AM -0300, Arnaldo Carvalho de Melo wrote: >> Em Wed, Dec 09, 2015 at 11:10:48AM +0900, Masami Hiramatsu escreveu: >> > In this series I've also tried to fix some object leaks in perf top

RE: [PATCH/RFC 01/16] perf top: Delete half-processed hist entries when exit

>From: Namhyung Kim [mailto:namhy...@kernel.org] > >After sample processing is done, hist entries are in both of >hists->entries and hists->entries_in (or hists->entries_collapsed). >So I guess perf report does not have leaks on hists. > >But for perf top, it's possible to have half-processed

RE: [PATCH perf/core 16/22] perf: Fix __cmd_top and perf_session__process_events to put the idle thread

>From: Arnaldo Carvalho de Melo [mailto:a...@kernel.org] > >Em Wed, Dec 09, 2015 at 11:11:23AM +0900, Masami Hiramatsu escreveu: >> Since perf_session__register_idle_thread() got the idle thread, >> caller functions have to put it afterwards. >> Note that since the thread was already inserted to

RE: [PATCH 2/2 (v2)] perf tools: Prevent calling machine__delete() on non-allocated machine

Hi Wang, >From: Wang Nan [mailto:wangn...@huawei.com] > >To prevent futher commits calling machine__delete() on non-allocated >'struct machine' (which would cause memory corruption), this patch >enforces machine__init(), record whether a machine structure is >dynamically allocated or not, and

RE: [PATCH perf/core 00/22] perf refcnt debugger API and fixes

>From: Arnaldo Carvalho de Melo [mailto:a...@kernel.org] > >Em Wed, Dec 09, 2015 at 11:10:48AM +0900, Masami Hiramatsu escreveu: >> Hi Arnaldo, >> >> Here is a series of patches for perf refcnt debugger and >> some fixes. >> >> In this series I've replaced all atomic reference counters >> with the

RE: [PATCH perf/core 00/22] perf refcnt debugger API and fixes

From: 'Arnaldo Carvalho de Melo' [mailto:a...@kernel.org] > >But this requires having these special refcnt__ routines, that will make >tools/perf/ code patterns for reference counts look different that the >refcount patterns in the kernel :-\ BTW, I think even without the refcnt debugger, we'd

RE: [PATCH perf/core 00/22] perf refcnt debugger API and fixes

From: Wangnan (F) [mailto:wangn...@huawei.com] > > >On 2015/12/11 10:15, 平松雅巳 / HIRAMATU，MASAMI wrote: >> From: 'Arnaldo Carvalho de Melo' [mailto:a...@kernel.org] >>> But this requires having these special refcnt__ routines, that will make >>> tools/perf/ code p

RE: [PATCH perf/core 00/22] perf refcnt debugger API and fixes

From: Wangnan (F) [mailto:wangn...@huawei.com] >On 2015/12/10 23:12, 'Arnaldo Carvalho de Melo' wrote: > >[SNIP] >> But this requires having these special refcnt__ routines, that will make >> tools/perf/ code patterns for reference counts look different that the >> refcount patterns in the kernel

RE: [PATCH resend] perf machine: Pass correct string to dso__adjust_kmod_long_name

>From: Wang Nan [mailto:wangn...@huawei.com] > >There's a mistake in dso__adjust_kmod_long_name() that, it use strdup() >to dup the new long_name of a dso, but passes the original string >to dso__set_long_name(). Which causes random crash during cleanup. > Looks good to me:) Reviewed-by: Masami

RE: [PATCH resend] perf machine: Pass correct string to dso__adjust_kmod_long_name

>From: Wang Nan [mailto:wangn...@huawei.com] > >There's a mistake in dso__adjust_kmod_long_name() that, it use strdup() >to dup the new long_name of a dso, but passes the original string >to dso__set_long_name(). Which causes random crash during cleanup. > Looks good to me:) Reviewed-by: Masami

RE: [PATCH v3] perf tools: Introduce perf_thread for backtrace

Hi Namhyung, >From: Namhyung Kim [mailto:namhy...@gmail.com] On Behalf Of Namhyung Kim > >Hi Masami, > >On Thu, Dec 03, 2015 at 07:13:15AM +, 平松雅巳 / HIRAMATU，MASAMI wrote: >> From: Namhyung Kim [mailto:namhy...@kernel.org] >> > >> >On Thu, Dec 03, 20

RE: [PATCH v3] perf tools: Introduce perf_thread for backtrace

Hi Namhyung, >From: Namhyung Kim [mailto:namhy...@gmail.com] On Behalf Of Namhyung Kim > >Hi Masami, > >On Thu, Dec 03, 2015 at 07:13:15AM +, 平松雅巳 / HIRAMATU，MASAMI wrote: >> From: Namhyung Kim [mailto:namhy...@kernel.org] >> > >> >On Thu, Dec 03, 20

RE: [PATCH v3] perf tools: Introduce perf_thread for backtrace

From: Namhyung Kim [mailto:namhy...@kernel.org] > >On Thu, Dec 03, 2015 at 12:15:12AM +0000, 平松雅巳 / HIRAMATU，MASAMI wrote: >> >From: Namhyung Kim [mailto:namhy...@gmail.com] On Behalf Of Namhyung Kim >> > >> >Backtrace is a crucial info for debugging. And upco

RE: [PATCH v3] perf tools: Introduce perf_thread for backtrace

>From: Namhyung Kim [mailto:namhy...@gmail.com] On Behalf Of Namhyung Kim > >Backtrace is a crucial info for debugging. And upcoming refcnt >tracking facility also wants to use it. Note that the refcnt backtrace symbol resolution will work at exit. This means that it can not depend on the

RE: [PATCH v3] perf tools: Introduce perf_thread for backtrace

From: Namhyung Kim [mailto:namhy...@kernel.org] > >On Thu, Dec 03, 2015 at 12:15:12AM +0000, 平松雅巳 / HIRAMATU，MASAMI wrote: >> >From: Namhyung Kim [mailto:namhy...@gmail.com] On Behalf Of Namhyung Kim >> > >> >Backtrace is a crucial info for debugging. And upco

RE: [PATCH v3] perf tools: Introduce perf_thread for backtrace

>From: Namhyung Kim [mailto:namhy...@gmail.com] On Behalf Of Namhyung Kim > >Backtrace is a crucial info for debugging. And upcoming refcnt >tracking facility also wants to use it. Note that the refcnt backtrace symbol resolution will work at exit. This means that it can not depend on the

RE: [PATCH] perf probe: Adjust dso->long_name for offline module

From: Wang Nan [mailto:wangn...@huawei.com] > >If libelf unable to open debuginfo for an offline module but the ko has >symtab, something unexpected may happen. > > # rm -rf ~/.debug/ > # mv /usr/lib64/elfutils/libebl_x86_64.so{,.bak} Please do give more possible usecase. removing libebl is

RE: [PATCH] perf probe: Adjust dso->long_name for offline module

From: Wang Nan [mailto:wangn...@huawei.com] > >If libelf unable to open debuginfo for an offline module but the ko has >symtab, something unexpected may happen. > > # rm -rf ~/.debug/ > # mv /usr/lib64/elfutils/libebl_x86_64.so{,.bak} Please do give more possible usecase. removing libebl is

RE: [GIT PULL 00/37] perf/core improvements and fixes

>From: 'Arnaldo Carvalho de Melo' [mailto:a...@kernel.org] > >Em Fri, Nov 20, 2015 at 10:01:30AM +0000, 平松雅巳 / HIRAMATU，MASAMI escreveu: >> Hi Arnaldo, >> >> I just have a question about the refcnt debugger patch. It seems >> that the debugger itself is dropped fr

RE: [PATCH 1/2] perf tools: Always give options even it not compiled

>From: Wang Nan [mailto:wangn...@huawei.com] > >This patch keeps options of perf builtins same in all condition. If the >option is disabled because of compiling options, users should be >notified. > >This patch does it by introducing a series of new option macros, flags >and field in struct

RE: [GIT PULL 00/37] perf/core improvements and fixes

Hi Arnaldo, I just have a question about the refcnt debugger patch. It seems that the debugger itself is dropped from this series, would you have a plan to merge it afterwards? Since I'd like to change other refcnts with my refcnt API, and also to add some features, I'd like to decide I'd better

RE: [RFC/PATCH] perf tools: Introduce perf_thread for backtrace

>From: Namhyung Kim [mailto:namhy...@kernel.org] > >Backtrace is a crucial info for debugging. And upcoming refcnt >tracking facility also wants to use it. > >So instead of relying on glibc's backtrace_symbols[_fd] which misses >some (static) functions , use our own symbol searching mechanism.

RE: [PATCH 1/2] perf tools: Always give options even it not compiled

>From: Wang Nan [mailto:wangn...@huawei.com] > >This patch keeps options of perf builtins same in all condition. If the >option is disabled because of compiling options, users should be >notified. > >This patch does it by introducing a series of new option macros, flags >and field in struct

RE: [GIT PULL 00/37] perf/core improvements and fixes

Hi Arnaldo, I just have a question about the refcnt debugger patch. It seems that the debugger itself is dropped from this series, would you have a plan to merge it afterwards? Since I'd like to change other refcnts with my refcnt API, and also to add some features, I'd like to decide I'd better

RE: [GIT PULL 00/37] perf/core improvements and fixes

>From: 'Arnaldo Carvalho de Melo' [mailto:a...@kernel.org] > >Em Fri, Nov 20, 2015 at 10:01:30AM +0000, 平松雅巳 / HIRAMATU，MASAMI escreveu: >> Hi Arnaldo, >> >> I just have a question about the refcnt debugger patch. It seems >> that the debugger itself is dropped fr

RE: [RFC/PATCH] perf tools: Introduce perf_thread for backtrace

>From: Namhyung Kim [mailto:namhy...@kernel.org] > >Backtrace is a crucial info for debugging. And upcoming refcnt >tracking facility also wants to use it. > >So instead of relying on glibc's backtrace_symbols[_fd] which misses >some (static) functions , use our own symbol searching mechanism.

RE: [PATCH perf/core 03/13] perf: Introduce generic refcount APIs with debug feature

From: Namhyung Kim [mailto:namhy...@kernel.org] > >On Wed, Nov 18, 2015 at 03:40:16PM +0900, Masami Hiramatsu wrote: >> This is a kind of debugging feature for atomic reference counter. >> The reference counters are widely used in perf tools but not well >> debugged. It sometimes causes memory

RE: [PATCH perf/core 03/13] perf: Introduce generic refcount APIs with debug feature

From: Namhyung Kim [mailto:namhy...@kernel.org] > >On Wed, Nov 18, 2015 at 03:40:16PM +0900, Masami Hiramatsu wrote: >> This is a kind of debugging feature for atomic reference counter. >> The reference counters are widely used in perf tools but not well >> debugged. It sometimes causes memory

RE: [PATCH perf/core 02/13] perf: Make perf_exec_path always returns malloc'd string

From: Arnaldo Carvalho de Melo [mailto:a...@kernel.org] > >Em Wed, Nov 18, 2015 at 03:40:14PM +0900, Masami Hiramatsu escreveu: >> Since system_path() returns malloc'd string if given path is >> not an absolute path, perf_exec_path sometimes returns static >> string and sometimes returns malloc'd

RE: [PATCH perf/core 01/13] perf probe: Fix to free temporal Dwarf_Frame

From: Namhyung Kim [mailto:namhy...@gmail.com] >On November 19, 2015 7:36:39 AM GMT+09:00, Arnaldo Carvalho de Melo > wrote: >>Em Wed, Nov 18, 2015 at 03:40:12PM +0900, Masami Hiramatsu escreveu: >>> Since dwarf_cfi_addrframe returns malloc'd Dwarf_Frame >>> object, it has to be freed after used.

RE: [PATCH perf/core 00/13] perf memory/refcnt leak fixes

From: Arnaldo Carvalho de Melo [mailto:a...@kernel.org] > >Em Wed, Nov 18, 2015 at 03:40:09PM +0900, Masami Hiramatsu escreveu: >> Hi, >> >> Here is a series to fix some memory leaks and refcount >> leaks on map and dso. This also includes the refcnt APIs >> with backtrace debugging feature. >

RE: [PATCH perf/core 00/13] perf memory/refcnt leak fixes

From: Arnaldo Carvalho de Melo [mailto:a...@kernel.org] > >Em Wed, Nov 18, 2015 at 03:40:09PM +0900, Masami Hiramatsu escreveu: >> Hi, >> >> Here is a series to fix some memory leaks and refcount >> leaks on map and dso. This also includes the refcnt APIs >> with backtrace debugging feature. >

RE: [PATCH perf/core 01/13] perf probe: Fix to free temporal Dwarf_Frame

From: Namhyung Kim [mailto:namhy...@gmail.com] >On November 19, 2015 7:36:39 AM GMT+09:00, Arnaldo Carvalho de Melo > wrote: >>Em Wed, Nov 18, 2015 at 03:40:12PM +0900, Masami Hiramatsu escreveu: >>> Since dwarf_cfi_addrframe returns malloc'd Dwarf_Frame >>> object, it has to be

RE: [PATCH perf/core 02/13] perf: Make perf_exec_path always returns malloc'd string

From: Arnaldo Carvalho de Melo [mailto:a...@kernel.org] > >Em Wed, Nov 18, 2015 at 03:40:14PM +0900, Masami Hiramatsu escreveu: >> Since system_path() returns malloc'd string if given path is >> not an absolute path, perf_exec_path sometimes returns static >> string and sometimes returns malloc'd

RE: trace: trace_kprobe.c always shows interrupts off

Hi Mathieu, Steven, From: Steven Rostedt [mailto:rost...@goodmis.org] > >On Tue, 17 Nov 2015 16:35:35 + (UTC) >Mathieu Desnoyers wrote: > >> Hi, >> >> I notice that trace_kprobe.c does local_save_flags() within >> __kprobe_trace_func(), which is called (at least on x86) with >> interrupts

RE: trace: trace_kprobe.c always shows interrupts off

Hi Mathieu, Steven, From: Steven Rostedt [mailto:rost...@goodmis.org] > >On Tue, 17 Nov 2015 16:35:35 + (UTC) >Mathieu Desnoyers wrote: > >> Hi, >> >> I notice that trace_kprobe.c does local_save_flags() within >> __kprobe_trace_func(), which is called (at

RE: Re: [PATCH perf/core ] [BUGFIX] perf probe: Fix memory leaking on faiulre by clearing all probe_trace_events

From: Wangnan (F) [mailto:wangn...@huawei.com] > >Hi Masami, > >Today I remember the reason why I introduced patch [1]. Although your >patch is correct, >either [1] or [2] is still required, but they are both need to be fixed. > >Here is a bug: > >A segfault raises if use glob matching and

RE: [PATCH] perf probe: Clear probe_trace_event when add_probe_trace_event() fails

>From: Wang Nan [mailto:wangn...@huawei.com] > >When probe with glob, error in add_probe_trace_event() won't be passed >to debuginfo__find_trace_events() because it whould be modified by >probe_point_search_cb(). It causes segfault if perf failed to find >argument for one probing point matched by

RE: Re: [PATCH perf/core ] [BUGFIX] perf probe: Fix memory leaking on faiulre by clearing all probe_trace_events

From: Wangnan (F) [mailto:wangn...@huawei.com] > >Hi Masami, > >Today I remember the reason why I introduced patch [1]. Although your >patch is correct, >either [1] or [2] is still required, but they are both need to be fixed. > >Here is a bug: > >A segfault raises if use glob matching and

RE: [PATCH] perf probe: Clear probe_trace_event when add_probe_trace_event() fails

>From: Wang Nan [mailto:wangn...@huawei.com] > >When probe with glob, error in add_probe_trace_event() won't be passed >to debuginfo__find_trace_events() because it whould be modified by >probe_point_search_cb(). It causes segfault if perf failed to find >argument for one probing point matched by

RE: [RFC] kprobes: Use percpu counter to collect nhit statistics

From: Martin KaFai Lau [mailto:ka...@fb.com] > >When doing ebpf+kprobe on some hot TCP functions (e.g. >tcp_rcv_established), the kprobe_dispatcher shows up in 'perf report'. > >In kprobe_dispatcher(), there is a lot of cache bouncing >in 'tk->nhit++'. 'tk->nhit' and 'tk->tp.flags' also share

RE: [RFC] kprobes: Use percpu counter to collect nhit statistics

From: Martin KaFai Lau [mailto:ka...@fb.com] > >When doing ebpf+kprobe on some hot TCP functions (e.g. >tcp_rcv_established), the kprobe_dispatcher shows up in 'perf report'. > >In kprobe_dispatcher(), there is a lot of cache bouncing >in 'tk->nhit++'. 'tk->nhit' and 'tk->tp.flags' also share

RE: [PATCH] perf probe: Clear probe_trace_event when probe_trace_event failure

From: Wang Nan [mailto:wangn...@huawei.com] > >When failure occures in add_probe_trace_event(), to avoid potential >dangling pointer and memory leak, resource attached to 'struct >probe_trace_event' should be cleared. Oops, right. I've found actual memory leak and this fix is not enough, because

RE: [PATCH] perf probe: Clear probe_trace_event when probe_trace_event failure

From: Wang Nan [mailto:wangn...@huawei.com] > >When failure occures in add_probe_trace_event(), to avoid potential >dangling pointer and memory leak, resource attached to 'struct >probe_trace_event' should be cleared. Oops, right. I've found actual memory leak and this fix is not enough, because

RE: [PATCH v2] perf probe: Verify parameters for two functions

From: Wang Nan [mailto:wangn...@huawei.com] > >On kernel with only one of CONFIG_KPROBE_EVENTS and >CONFIG_UPROBE_EVENTS enabled, 'perf probe -d' causes segfault because >perf_del_probe_events() calls probe_file__get_events() with a negative >fd. > >This patch fixes it by add parameter validation

RE: [PATCH v2] perf probe: Verify parameters for two functions

From: Wang Nan [mailto:wangn...@huawei.com] > >On kernel with only one of CONFIG_KPROBE_EVENTS and >CONFIG_UPROBE_EVENTS enabled, 'perf probe -d' causes segfault because >perf_del_probe_events() calls probe_file__get_events() with a negative >fd. > >This patch fixes it by add parameter validation

RE: [PATCH 2/2] perf tools: Fix find_perf_probe_point_from_map() which incorrectly returns success

From: a...@kernel.org [mailto:a...@kernel.org] >> >>Em Thu, Nov 05, 2015 at 02:08:48PM +0000, 平松雅巳 / HIRAMATU，MASAMI escreveu: >>> From: Wang Nan [mailto:wangn...@huawei.com] >>> > >>> >It is possible that find_perf_probe_point_from_map() fails to

RE: [PATCH 2/2] perf tools: Fix find_perf_probe_point_from_map() which incorrectly returns success

From: a...@kernel.org [mailto:a...@kernel.org] > >Em Thu, Nov 05, 2015 at 02:08:48PM +0000, 平松雅巳 / HIRAMATU，MASAMI escreveu: >> From: Wang Nan [mailto:wangn...@huawei.com] >> > >> >It is possible that find_perf_probe_point_from_map() fails to find >> >symbol

RE: [PATCH 1/2] perf probe: Only call probe_file__get_events() when fd is valid

From: Arnaldo Carvalho de Melo [mailto:a...@kernel.org] >Em Thu, Nov 05, 2015 at 01:19:24PM +, Wang Nan escreveu: >> In system with kprobe enabled but uprobe turned off, 'perf probe -d' >> causes segfault because it calls probe_file__get_events() with a >> negative fd (when deleting uprobe

RE: [PATCH 00/28] tracing: 'hist' triggers

From: Namhyung Kim [mailto:namhy...@gmail.com] On Behalf Of Namhyung Kim > >Hi Tom, > >I implemented 'log2' modifier on top of your v11 patchset. Could you >please take a look at this? Ah, this seems very useful :) Reviewed-by: Masami Hiramatsu -- Masami > > > >From

RE: [PATCH 1/2] perf probe: Only call probe_file__get_events() when fd is valid

From: Wang Nan [mailto:wangn...@huawei.com] > >In system with kprobe enabled but uprobe turned off, 'perf probe -d' >causes segfault because it calls probe_file__get_events() with a >negative fd (when deleting uprobe events). Hmm, OK. This may happen if user runs perf probe on the kernel which

RE: [PATCH 2/2] perf tools: Fix find_perf_probe_point_from_map() which incorrectly returns success

From: Wang Nan [mailto:wangn...@huawei.com] > >It is possible that find_perf_probe_point_from_map() fails to find >symbol but still returns 0 because of an small error when coding: >find_perf_probe_point_from_map() set 'ret' to error code at first, >but also use it to hold return value of

RE: [PATCH 1/2] perf probe: Only call probe_file__get_events() when fd is valid

From: Wang Nan [mailto:wangn...@huawei.com] > >In system with kprobe enabled but uprobe turned off, 'perf probe -d' >causes segfault because it calls probe_file__get_events() with a >negative fd (when deleting uprobe events). Hmm, OK. This may happen if user runs perf probe on the kernel which

RE: [PATCH 2/2] perf tools: Fix find_perf_probe_point_from_map() which incorrectly returns success

From: a...@kernel.org [mailto:a...@kernel.org] > >Em Thu, Nov 05, 2015 at 02:08:48PM +0000, 平松雅巳 / HIRAMATU，MASAMI escreveu: >> From: Wang Nan [mailto:wangn...@huawei.com] >> > >> >It is possible that find_perf_probe_point_from_map() fails to find >> >symbol

RE: [PATCH 2/2] perf tools: Fix find_perf_probe_point_from_map() which incorrectly returns success

From: a...@kernel.org [mailto:a...@kernel.org] >> >>Em Thu, Nov 05, 2015 at 02:08:48PM +0000, 平松雅巳 / HIRAMATU，MASAMI escreveu: >>> From: Wang Nan [mailto:wangn...@huawei.com] >>> > >>> >It is possible that find_perf_probe_point_from_map() fails to

RE: [PATCH 00/28] tracing: 'hist' triggers

From: Namhyung Kim [mailto:namhy...@gmail.com] On Behalf Of Namhyung Kim > >Hi Tom, > >I implemented 'log2' modifier on top of your v11 patchset. Could you >please take a look at this? Ah, this seems very useful :) Reviewed-by: Masami Hiramatsu -- Masami > >

  1   2   3   >