Forgot to free uprobe_cpu_buffer percpu page in uprobe_buffer_disable.
Signed-off-by: zhangwei(Jovi)
---
kernel/trace/trace_uprobe.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index e447336..071d3bb 100644
--- a/kernel
Forgot to free uprobe_cpu_buffer percpu page in uprobe_buffer_disable.
Signed-off-by: zhangwei(Jovi) jovi.zhang...@huawei.com
---
kernel/trace/trace_uprobe.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index e447336..071d3bb
Hi Namhyung,
On 2014/1/17 16:08, Namhyung Kim wrote:
> Hello,
> (Resending with LKML CC'ed)
>
> This patchset tries to add support for recent multi buffer and event
> trigger changes to uprobes. The multi buffer support patch is an
> updated version of Zovi's previous patch v6 [1].
>
> Zovi,
Hi Namhyung,
On 2014/1/17 16:08, Namhyung Kim wrote:
Hello,
(Resending with LKML CC'ed)
This patchset tries to add support for recent multi buffer and event
trigger changes to uprobes. The multi buffer support patch is an
updated version of Zovi's previous patch v6 [1].
Zovi, please
store_trace_args() to reduce
> code duplication.
>
> Cc: Masami Hiramatsu
> Cc: Srikar Dronamraju
> Cc: Oleg Nesterov
> Cc: zhangwei(Jovi)
> Cc: Arnaldo Carvalho de Melo
> Signed-off-by: Namhyung Kim
> ---
> kernel/trace/trace_uprobe.c | 97
> +
() to reduce
code duplication.
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Srikar Dronamraju sri...@linux.vnet.ibm.com
Cc: Oleg Nesterov o...@redhat.com
Cc: zhangwei(Jovi) jovi.zhang...@huawei.com
Cc: Arnaldo Carvalho de Melo a...@ghostprotocols.net
Signed-off-by: Namhyung Kim namhy
On 2013/8/23 0:42, Steven Rostedt wrote:
> On Fri, 09 Aug 2013 18:56:54 +0900
> Masami Hiramatsu wrote:
>
>> (2013/08/09 17:45), Namhyung Kim wrote:
>>> From: Namhyung Kim
>>>
>>> Fetching from user space should be done in a non-atomic context. So
>>> use a temporary buffer and copy its
On 2013/8/23 0:42, Steven Rostedt wrote:
On Fri, 09 Aug 2013 18:56:54 +0900
Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
(2013/08/09 17:45), Namhyung Kim wrote:
From: Namhyung Kim namhyung@lge.com
Fetching from user space should be done in a non-atomic context. So
use a
On 2013/8/12 23:26, Karim Yaghmour wrote:
>
> On 13-08-11 11:24 PM, zhangwei(Jovi) wrote:
>> If you want to base on ftrace, below two approach maybe take into use:
>>
>> - register_ftrace_function/unregister_ftrace_function
>>
>> - perf_event_create_ke
On 2013/8/12 23:26, Karim Yaghmour wrote:
On 13-08-11 11:24 PM, zhangwei(Jovi) wrote:
If you want to base on ftrace, below two approach maybe take into use:
- register_ftrace_function/unregister_ftrace_function
- perf_event_create_kernel_counter (function event id is 1)
the first one
On 2013/8/12 17:34, Jiri Olsa wrote:
> Adding initialization check in trace_printk for *puts
> paths, plus unifying the check for all related cases.
>
> Cc: Steven Rostedt
> Cc: Frederic Weisbecker
> Cc: Ingo Molnar
> ---
Missed Signed-off-by tag?
> kernel/trace/trace.c | 15 ---
On 2013/8/12 17:34, Jiri Olsa wrote:
Adding initialization check in trace_printk for *puts
paths, plus unifying the check for all related cases.
Cc: Steven Rostedt rost...@goodmis.org
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi...@redhat.com
---
Missed Signed-off-by tag?
On 2013/8/12 8:03, Karim Yaghmour wrote:
>
> Wondering if there's a way for reading perf counters in the kernel. I'd
> like to read/record perf counters on ftrace function tracing
> entries/exits to provide a rundown of the value of various counters on
> function call boundaries.
>
> [ Steven:
On 2013/8/12 8:03, Karim Yaghmour wrote:
Wondering if there's a way for reading perf counters in the kernel. I'd
like to read/record perf counters on ftrace function tracing
entries/exits to provide a rundown of the value of various counters on
function call boundaries.
[ Steven:
On Sat, Aug 10, 2013 at 9:41 AM, zhangwei(Jovi) wrote:
> On Sat, Aug 10, 2013 at 9:26 AM, zhangwei(Jovi)
> wrote:
>> On Sat, Aug 10, 2013 at 12:20 AM, Oleg Nesterov wrote:
>>>
>>> Sorry, I didn't read this series yet. Not that I think this needs my
>>>
On Sat, Aug 10, 2013 at 9:41 AM, zhangwei(Jovi) jovi.zhang...@gmail.com wrote:
On Sat, Aug 10, 2013 at 9:26 AM, zhangwei(Jovi) jovi.zhang...@gmail.com
wrote:
On Sat, Aug 10, 2013 at 12:20 AM, Oleg Nesterov o...@redhat.com wrote:
Sorry, I didn't read this series yet. Not that I think
On Sat, Aug 10, 2013 at 9:26 AM, zhangwei(Jovi) wrote:
> On Sat, Aug 10, 2013 at 12:20 AM, Oleg Nesterov wrote:
>>
>> Sorry, I didn't read this series yet. Not that I think this needs my
>> help, but I'll try to do this a later...
>>
>> On 08/09, Masami Hiramats
On Sat, Aug 10, 2013 at 12:20 AM, Oleg Nesterov wrote:
>
> Sorry, I didn't read this series yet. Not that I think this needs my
> help, but I'll try to do this a later...
>
> On 08/09, Masami Hiramatsu wrote:
> >
> > I just concern using kmalloc() in the event handler.
>
> GFP_KERNEL should be
On Sat, Aug 10, 2013 at 12:20 AM, Oleg Nesterov o...@redhat.com wrote:
Sorry, I didn't read this series yet. Not that I think this needs my
help, but I'll try to do this a later...
On 08/09, Masami Hiramatsu wrote:
I just concern using kmalloc() in the event handler.
GFP_KERNEL should
On Sat, Aug 10, 2013 at 9:26 AM, zhangwei(Jovi) jovi.zhang...@gmail.com wrote:
On Sat, Aug 10, 2013 at 12:20 AM, Oleg Nesterov o...@redhat.com wrote:
Sorry, I didn't read this series yet. Not that I think this needs my
help, but I'll try to do this a later...
On 08/09, Masami Hiramatsu wrote
Hi,
ktap was released 0.2 at several days ago, you can read the release note
in: http://lwn.net/Articles/561568/
The public location of ktap is in: https://github.com/ktap/ktap.git
ktap v0.2 release brought a lots of new valuable changes, in summary,
the architecture of ktap is easy to
Hi,
ktap was released 0.2 at several days ago, you can read the release note
in: http://lwn.net/Articles/561568/
The public location of ktap is in: https://github.com/ktap/ktap.git
ktap v0.2 release brought a lots of new valuable changes, in summary,
the architecture of ktap is easy to
On 2013/7/18 16:31, zhangwei(Jovi) wrote:
> Currently trace option stacktrace is not applicable for
> trace_printk with constant string argument, the reason is
> there missed ftrace_trace_stack in __trace_puts/__trace_bputs.
>
> In contrast, when using trace_printk with not
On 2013/7/27 14:35, zhangwei(Jovi) wrote:
> A bug was found in events/sched/sched_switch/format.
>
> field:char prev_comm[32]; offset:8; size:16;
> signed:1;
>
> and prev_comm field is defined as:
>
> __array(char, prev_
On 2013/7/27 14:35, zhangwei(Jovi) wrote:
A bug was found in events/sched/sched_switch/format.
field:char prev_comm[32]; offset:8; size:16;
signed:1;
and prev_comm field is defined as:
__array(char, prev_comm, TASK_COMM_LEN )
Note
On 2013/7/18 16:31, zhangwei(Jovi) wrote:
Currently trace option stacktrace is not applicable for
trace_printk with constant string argument, the reason is
there missed ftrace_trace_stack in __trace_puts/__trace_bputs.
In contrast, when using trace_printk with not constant string
argument
On 2013/7/31 18:01, zhangwei(Jovi) wrote:
> From: Ingo Molnar
>
> When I'm using ktap script to tracing all event tracepoints by relay
> transport, without this patch, the system will hang in few seconds.
>
> I found the original patch discussion in 2007.
> http://marc
.
Original patch changelog from Ingo in 2007:
Remove timer calls (!!!) from deep within the tracing infrastructure.
This was totally bogus code that can cause lockups and worse.
Poll the buffer every 2 jiffies for now.
Signed-off-by: Ingo Molnar
Signed-off-by: "zhangwei(Jovi)"
-by: zhangwei(Jovi) jovi.zhang...@huawei.com
Cc: Dan Carpenter dan.carpen...@oracle.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Jens Axboe ax...@kernel.dk
Cc: Al Viro v...@zeniv.linux.org.uk
Cc: Eric Dumazet eduma...@google.com
---
kernel/relay.c | 14 +-
1 file changed, 5 insertions(+), 9
On 2013/7/31 18:01, zhangwei(Jovi) wrote:
From: Ingo Molnar mi...@elte.hu
When I'm using ktap script to tracing all event tracepoints by relay
transport, without this patch, the system will hang in few seconds.
I found the original patch discussion in 2007.
http://marc.info/?l=linux
Dear,
I'm pleased to announce that ktap released v0.2, the archive is available at:
https://github.com/ktap/ktap/archive/v0.2.tar.gz
= what's ktap?
A New Scripting Dynamic Tracing Tool For Linux
ktap have different design principles from Linux mainstream dynamic tracing
Dear,
I'm pleased to announce that ktap released v0.2, the archive is available at:
https://github.com/ktap/ktap/archive/v0.2.tar.gz
= what's ktap?
A New Scripting Dynamic Tracing Tool For Linux
ktap have different design principles from Linux mainstream dynamic tracing
Changed from v2:
mod timer interval changed from HZ/10 to jiffies + HZ/10,
as Dan Carpenter suggested.
This patch is based on -mm tree.
Signed-off-by: zhangwei(Jovi)
Cc: Dan Carpenter
Cc: Ingo Molnar
Cc: Steven Rostedt
Cc: Jens Axboe
Cc: Al Viro
Cc: Eric Dumazet
---
kernel/relay.c |4
not core kernel data, then copy the storage.
This patch also kill the global storage event_storage.
events/sched/sched_switch/format changed after patch:
field:char prev_comm[16]; offset:8; size:16;
signed:1;
Signed-off-by: zhangwei(Jovi)
---
include/linux
not core kernel data, then copy the storage.
This patch also kill the global storage event_storage.
events/sched/sched_switch/format changed after patch:
field:char prev_comm[16]; offset:8; size:16;
signed:1;
Signed-off-by: zhangwei(Jovi) jovi.zhang...@huawei.com
Changed from v2:
mod timer interval changed from HZ/10 to jiffies + HZ/10,
as Dan Carpenter suggested.
This patch is based on -mm tree.
Signed-off-by: zhangwei(Jovi) jovi.zhang...@huawei.com
Cc: Dan Carpenter dan.carpen...@oracle.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Steven Rostedt rost
On 2013/7/19 9:29, Steven Rostedt wrote:
> On Mon, 2013-07-15 at 16:32 +0800, zhangwei(Jovi) wrote:
>> diff --git a/kernel/trace/trace_functions_graph.c
>> b/kernel/trace/trace_functions_graph.c
>> index 8388bc9..3793f90 100644
>> --- a/kernel/trace/trace_functions_gr
Variable tracing_selftest_disabled have not any sense when
CONFIG_FTRACE_STARTUP_TEST is disabled.
Signed-off-by: zhangwei(Jovi)
---
kernel/trace/trace.c|4 +++-
kernel/trace/trace.h|2 +-
kernel/trace/trace_events.c |2 ++
3 files changed, 6 insertions(+), 2
), then
trace option stacktrace is workable, this inconstant result
will confusing user a lot.
Signed-off-by: zhangwei(Jovi)
---
kernel/trace/trace.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 3d5a931..4d70cc5
There missed TRACE_ITER_PRINTK check in __trace_puts/__trace_bputs,
so add it, to constant with __trace_printk/__trace_bprintk,
those functions mainly called by same function: trace_printk.
Signed-off-by: zhangwei(Jovi)
---
kernel/trace/trace.c |6 ++
1 file changed, 6 insertions
There missed TRACE_ITER_PRINTK check in __trace_puts/__trace_bputs,
so add it, to constant with __trace_printk/__trace_bprintk,
those functions mainly called by same function: trace_printk.
Signed-off-by: zhangwei(Jovi) jovi.zhang...@huawei.com
---
kernel/trace/trace.c |6 ++
1 file
), then
trace option stacktrace is workable, this inconstant result
will confusing user a lot.
Signed-off-by: zhangwei(Jovi) jovi.zhang...@huawei.com
---
kernel/trace/trace.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
Variable tracing_selftest_disabled have not any sense when
CONFIG_FTRACE_STARTUP_TEST is disabled.
Signed-off-by: zhangwei(Jovi) jovi.zhang...@huawei.com
---
kernel/trace/trace.c|4 +++-
kernel/trace/trace.h|2 +-
kernel/trace/trace_events.c |2 ++
3 files changed, 6
On 2013/7/19 9:29, Steven Rostedt wrote:
On Mon, 2013-07-15 at 16:32 +0800, zhangwei(Jovi) wrote:
diff --git a/kernel/trace/trace_functions_graph.c
b/kernel/trace/trace_functions_graph.c
index 8388bc9..3793f90 100644
--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace
We should use CONFIG_STACK_TRACER to guard readme text
of stack tracer related file, not CONFIG_STACKTRACE.
Signed-off-by: zhangwei(Jovi)
---
kernel/trace/trace.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index e71a8be
There have some mismatch between comments with
real function name, update it.
This patch also add some missed function arguments
description.
Signed-off-by: zhangwei(Jovi)
---
kernel/trace/ring_buffer.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git
Hi Steven,
This patchset don't have big change on tracing, just three minor fix,
please check it.
Thanks.
zhangwei(Jovi) (3):
tracing: use correct config guard CONFIG_STACK_TRACER
tracing: use trace_seq_puts()/trace_seq_putc() where possible
tracing: update typo of ring buffer comments
For string without format specifiers, use trace_seq_puts()
or trace_seq_putc().
Signed-off-by: zhangwei(Jovi)
---
kernel/trace/ring_buffer.c | 10 +++
kernel/trace/trace_events_filter.c |4 +--
kernel/trace/trace_functions_graph.c | 52
For string without format specifiers, use trace_seq_puts()
or trace_seq_putc().
Signed-off-by: zhangwei(Jovi) jovi.zhang...@huawei.com
---
kernel/trace/ring_buffer.c | 10 +++
kernel/trace/trace_events_filter.c |4 +--
kernel/trace/trace_functions_graph.c | 52
Hi Steven,
This patchset don't have big change on tracing, just three minor fix,
please check it.
Thanks.
zhangwei(Jovi) (3):
tracing: use correct config guard CONFIG_STACK_TRACER
tracing: use trace_seq_puts()/trace_seq_putc() where possible
tracing: update typo of ring buffer comments
There have some mismatch between comments with
real function name, update it.
This patch also add some missed function arguments
description.
Signed-off-by: zhangwei(Jovi) jovi.zhang...@huawei.com
---
kernel/trace/ring_buffer.c | 16 +---
1 file changed, 9 insertions(+), 7
We should use CONFIG_STACK_TRACER to guard readme text
of stack tracer related file, not CONFIG_STACKTRACE.
Signed-off-by: zhangwei(Jovi) jovi.zhang...@huawei.com
---
kernel/trace/trace.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel
and worse.
Poll the buffer every 2 jiffies for now.
Signed-off-by: Ingo Molnar
Signed-off-by: "zhangwei(Jovi)"
Cc: Steven Rostedt
Cc: Jens Axboe
Cc: Al Viro
Cc: Eric Dumazet
Signed-off-by: Andrew Morton
---
kernel/relay.c | 14 +-
1 file changed, 5 insertions(+), 9 deletion
and worse.
Poll the buffer every 2 jiffies for now.
Signed-off-by: Ingo Molnar mi...@elte.hu
Signed-off-by: zhangwei(Jovi) jovi.zhang...@huawei.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Jens Axboe ax...@kernel.dk
Cc: Al Viro v...@zeniv.linux.org.uk
Cc: Eric Dumazet eduma...@google.com
Signed-off
ge
- fix flags race in probe_event_disable
zhangwei(Jovi) (2):
tracing/uprobes: Support ftrace_event_file base multibuffer
tracing/uprobes: Support soft-mode disabling
kernel/trace/trace_uprobe.c | 122 ---
1 file changed, 103 insertions(+), 19 deleti
Support soft-mode disabling on uprobe-based dynamic events.
Soft-disabling is just ignoring recording if the soft disabled
flag is set.
Signed-off-by: zhangwei(Jovi)
Cc: Masami Hiramatsu
Cc: Frederic Weisbecker
Cc: Oleg Nesterov
Cc: Srikar Dronamraju
---
kernel/trace/trace_uprobe.c |3
are still mutually exclusive
in probe_event_enable currently, this means we cannot allow
one user is using uprobe-tracer, and another user is using
perf-probe on same uprobe concurrently.
(Perhaps this will be fix in future, kprobe don't have this
limitation now)
Signed-off-by: zhangwei(Jovi)
Cc
; limitation now)
>
> So why does this limitation exist? Didn't we support this kind of thing
> in the original code?
>
Yes, it existed(maybe not exist before uprobe pre-filter work), because uprobe
filter
is associated with trace_uprobe tightly at present, so we cannot assign
TP_FLAG
are still mutually exclusive
in probe_event_enable currently, this means we cannot allow
one user is using uprobe-tracer, and another user is using
perf-probe on same uprobe concurrently.
(Perhaps this will be fix in future, kprobe dont't have this
limitation now)
Signed-off-by: zhangwei(Jovi)
Cc
obe_event_enable, found by Srikar.
v3:
- separate soft-mode disabling patch from multibuffer support patch.
- fix some comments
- coding style trivial
- fix flags race in probe_event_disable
zhangwei(Jovi) (2):
tracing/uprobes: Support ftrace_event_file base multibuffer
tracing/uprobes: Support sof
are still mutually exclusive
in probe_event_enable currently, this means we cannot allow
one user is using uprobe-tracer, and another user is using
perf-probe on same uprobe concurrently.
(Perhaps this will be fix in future, kprobe dont't have this
limitation now)
Signed-off-by: zhangwei(Jovi)
Cc
Support soft-mode disabling on uprobe-based dynamic events.
Soft-disabling is just ignoring recording if the soft disabled
flag is set.
Signed-off-by: zhangwei(Jovi)
Cc: Masami Hiramatsu
Cc: Frederic Weisbecker
Cc: Oleg Nesterov
Cc: Srikar Dronamraju
---
kernel/trace/trace_uprobe.c |3
are still mutually exclusive
in probe_event_enable currently, this means we cannot allow
one user is using uprobe-tracer, and another user is using
perf-probe on same uprobe concurrently.
(Perhaps this will be fix in future, kprobe dont't have this
limitation now)
Signed-off-by: zhangwei(Jovi
Support soft-mode disabling on uprobe-based dynamic events.
Soft-disabling is just ignoring recording if the soft disabled
flag is set.
Signed-off-by: zhangwei(Jovi) jovi.zhan...@huawei.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Oleg
by Srikar.
v3:
- separate soft-mode disabling patch from multibuffer support patch.
- fix some comments
- coding style trivial
- fix flags race in probe_event_disable
zhangwei(Jovi) (2):
tracing/uprobes: Support ftrace_event_file base multibuffer
tracing/uprobes: Support soft-mode disabling
are still mutually exclusive
in probe_event_enable currently, this means we cannot allow
one user is using uprobe-tracer, and another user is using
perf-probe on same uprobe concurrently.
(Perhaps this will be fix in future, kprobe dont't have this
limitation now)
Signed-off-by: zhangwei(Jovi
uprobe
filter
is associated with trace_uprobe tightly at present, so we cannot assign
TP_FLAG_PROFILE/TP_FLAG_TRACE for same trace_uprobe with different filter.
Perhaps we need to remove the limitation in future.
Signed-off-by: zhangwei(Jovi) jovi.zhang...@huawei.com
Cc: Masami Hiramatsu
are still mutually exclusive
in probe_event_enable currently, this means we cannot allow
one user is using uprobe-tracer, and another user is using
perf-probe on same uprobe concurrently.
(Perhaps this will be fix in future, kprobe don't have this
limitation now)
Signed-off-by: zhangwei(Jovi
Support soft-mode disabling on uprobe-based dynamic events.
Soft-disabling is just ignoring recording if the soft disabled
flag is set.
Signed-off-by: zhangwei(Jovi) jovi.zhan...@huawei.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Oleg
in probe_event_disable
zhangwei(Jovi) (2):
tracing/uprobes: Support ftrace_event_file base multibuffer
tracing/uprobes: Support soft-mode disabling
kernel/trace/trace_uprobe.c | 122 ---
1 file changed, 103 insertions(+), 19 deletions(-)
--
1.7.9.7
On 2013/7/3 7:56, Steven Rostedt wrote:
> On Wed, 2013-04-10 at 11:26 +0800, zhangwei(Jovi) wrote:
>> From: "zhangwei(Jovi)"
>>
>> Variable tracing_selftest_disabled have not any sense when
>> CONFIG_FTRACE_STARTUP_TEST is disabled.
>>
>> This
On 2013/7/3 7:19, Steven Rostedt wrote:
> On Wed, 2013-04-10 at 11:26 +0800, zhangwei(Jovi) wrote:
>> From: "zhangwei(Jovi)"
>>
>> Prepare for expose event tracing infrastructure.
>> (struct trace_array shall be use by external modules)
>>
>
> Wha
On 2013/7/3 7:35, Steven Rostedt wrote:
> On Wed, 2013-04-10 at 11:26 +0800, zhangwei(Jovi) wrote:
>> From: "zhangwei(Jovi)"
>>
>> Currently event tracing only can be use for ftrace and perf,
>> there don't have any mechanism to let modules(like external traci
On 2013/7/2 5:10, Oleg Nesterov wrote:
> On 07/01, Oleg Nesterov wrote:
>>
>> On 06/29, zhangwei(Jovi) wrote:
>>>
>>> [v3->v4]:
>>
>> I am wondering how much you will hate me if I suggest to make v5 ;)
>>
>> But look, imho prob
On 2013/7/2 4:27, Oleg Nesterov wrote:
> On 06/29, zhangwei(Jovi) wrote:
>>
>> [v3->v4]:
>
> I am wondering how much you will hate me if I suggest to make v5 ;)
>
Feel free to do that :)
> But look, imho probe_event_enable() looks a bit more confusing than
> it
On 2013/7/3 7:35, Steven Rostedt wrote:
On Wed, 2013-04-10 at 11:26 +0800, zhangwei(Jovi) wrote:
From: zhangwei(Jovi) jovi.zhang...@huawei.com
Currently event tracing only can be use for ftrace and perf,
there don't have any mechanism to let modules(like external tracing tool)
register
On 2013/7/3 7:19, Steven Rostedt wrote:
On Wed, 2013-04-10 at 11:26 +0800, zhangwei(Jovi) wrote:
From: zhangwei(Jovi) jovi.zhang...@huawei.com
Prepare for expose event tracing infrastructure.
(struct trace_array shall be use by external modules)
What module is going to be using
On 2013/7/3 7:56, Steven Rostedt wrote:
On Wed, 2013-04-10 at 11:26 +0800, zhangwei(Jovi) wrote:
From: zhangwei(Jovi) jovi.zhang...@huawei.com
Variable tracing_selftest_disabled have not any sense when
CONFIG_FTRACE_STARTUP_TEST is disabled.
This patch also remove __read_mostly attribute
On 2013/7/2 4:27, Oleg Nesterov wrote:
On 06/29, zhangwei(Jovi) wrote:
[v3-v4]:
I am wondering how much you will hate me if I suggest to make v5 ;)
Feel free to do that :)
But look, imho probe_event_enable() looks a bit more confusing than
it needs.
-probe_event_enable(struct
On 2013/7/2 5:10, Oleg Nesterov wrote:
On 07/01, Oleg Nesterov wrote:
On 06/29, zhangwei(Jovi) wrote:
[v3-v4]:
I am wondering how much you will hate me if I suggest to make v5 ;)
But look, imho probe_event_enable() looks a bit more confusing than
it needs.
And I am a bit worried
On 2013/7/1 20:32, Masami Hiramatsu wrote:
> (2013/06/29 18:30), zhangwei(Jovi) wrote:
>>> This patchset implements 'trace event triggers', which are similar to
>>> the function triggers implemented for 'ftrace filter commands' (see
>>> 'Filter commands' in
On 2013/7/1 23:49, Tom Zanussi wrote:
> Hi jovi,
>
> On Sat, 2013-06-29 at 17:30 +0800, zhangwei(Jovi) wrote:
>> On 2013/6/29 13:08, Tom Zanussi wrote:
>>> Hi,
>>>
>>> This is v2 of the trace event triggers patchset, addressing comments
>>> from
On 2013/7/1 23:49, Tom Zanussi wrote:
Hi jovi,
On Sat, 2013-06-29 at 17:30 +0800, zhangwei(Jovi) wrote:
On 2013/6/29 13:08, Tom Zanussi wrote:
Hi,
This is v2 of the trace event triggers patchset, addressing comments
from Masami Hiramatsu, zhangwei(Jovi), and Steve Rostedt (thanks
On 2013/7/1 20:32, Masami Hiramatsu wrote:
(2013/06/29 18:30), zhangwei(Jovi) wrote:
This patchset implements 'trace event triggers', which are similar to
the function triggers implemented for 'ftrace filter commands' (see
'Filter commands' in Documentation/trace/ftrace.txt), but instead
On 2013/6/29 13:08, Tom Zanussi wrote:
> Hi,
>
> This is v2 of the trace event triggers patchset, addressing comments
> from Masami Hiramatsu, zhangwei(Jovi), and Steve Rostedt (thanks for
> reviewing v1).
>
> v2:
> - removed all changes to __ftrace_event_enable_disable(
_event_enable currently, this means we cannot allow
one user is using uprobe-tracer, and another user is using
perf-probe on same uprobe concurrently.
(Perhaps this will be fix in future, kprobe dont't have this
limitation now)
Signed-off-by: zhangwei(Jovi)
Cc: Masami Hiramatsu
Cc: Frederic Weisbec
On 2013/6/29 13:08, Tom Zanussi wrote:
> Add support for SOFT_DISABLE to syscall events.
>
> The original SOFT_DISABLE patches didn't add support for soft disable
> of syscall events; this adds it and paves the way for future patches
> allowing triggers to be added to syscall events, since
On 2013/6/29 13:08, Tom Zanussi wrote:
Add support for SOFT_DISABLE to syscall events.
The original SOFT_DISABLE patches didn't add support for soft disable
of syscall events; this adds it and paves the way for future patches
allowing triggers to be added to syscall events, since triggers
, this means we cannot allow
one user is using uprobe-tracer, and another user is using
perf-probe on same uprobe concurrently.
(Perhaps this will be fix in future, kprobe dont't have this
limitation now)
Signed-off-by: zhangwei(Jovi) jovi.zhang...@huawei.com
Cc: Masami Hiramatsu masami.hiramatsu
On 2013/6/29 13:08, Tom Zanussi wrote:
Hi,
This is v2 of the trace event triggers patchset, addressing comments
from Masami Hiramatsu, zhangwei(Jovi), and Steve Rostedt (thanks for
reviewing v1).
v2:
- removed all changes to __ftrace_event_enable_disable() (except
for patch 04/11
On 2013/6/27 20:12, Srikar Dronamraju wrote:
> * zhangwei(Jovi) [2013-06-25 11:30:20]:
>
>> Support multi-buffer on uprobe-based dynamic events by
>> using ftrace_event_file.
>>
>> This patch is based kprobe-based dynamic events multibuffer
>> support work
On 2013/6/27 20:12, Srikar Dronamraju wrote:
* zhangwei(Jovi) jovi.zhang...@huawei.com [2013-06-25 11:30:20]:
Support multi-buffer on uprobe-based dynamic events by
using ftrace_event_file.
This patch is based kprobe-based dynamic events multibuffer
support work initially, commited
On 2013/6/25 18:10, Masami Hiramatsu wrote:
> (2013/06/25 17:15), zhangwei(Jovi) wrote:
>> There have no good reason to call free_trace_probe
>> every time when unregister_trace_probe return 0.
>>
>> Move free_trace_probe into unregister_trace_probe,
>> ma
There have no good reason to call free_trace_probe
every time when unregister_trace_probe return 0.
Move free_trace_probe into unregister_trace_probe,
make code simpler.
Signed-off-by: zhangwei(Jovi)
Cc: Masami Hiramatsu
Cc: Oleg Nesterov
---
kernel/trace/trace_kprobe.c |5 +
1 file
We cannot unregister trace_uprobe when trace_uprobe is in use,
otherwise resource will leak.
Just return -EBUSY if user want to unregister a trace_uprobe
which in use.
Signed-off-by: zhangwei(Jovi)
Cc: Masami Hiramatsu
Cc: Frederic Weisbecker
Cc: Oleg Nesterov
Cc: Srikar Dronamraju
Hi,
This patchset change some logic on events unregistering of kprobes/uprobes
patch 1: kprobes event unregister cleanup
patch 2: fix a bug when calling unregister trace_uprobe
zhangwei(Jovi) (2):
tracing/kprobes: move free_trace_probe into unregister_trace_probe
tracing/uprobes: disallow
Hi,
This patchset change some logic on events unregistering of kprobes/uprobes
patch 1: kprobes event unregister cleanup
patch 2: fix a bug when calling unregister trace_uprobe
zhangwei(Jovi) (2):
tracing/kprobes: move free_trace_probe into unregister_trace_probe
tracing/uprobes: disallow
We cannot unregister trace_uprobe when trace_uprobe is in use,
otherwise resource will leak.
Just return -EBUSY if user want to unregister a trace_uprobe
which in use.
Signed-off-by: zhangwei(Jovi) jovi.zhang...@huawei.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Frederic
There have no good reason to call free_trace_probe
every time when unregister_trace_probe return 0.
Move free_trace_probe into unregister_trace_probe,
make code simpler.
Signed-off-by: zhangwei(Jovi) jovi.zhang...@huawei.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Oleg Nesterov
On 2013/6/25 18:10, Masami Hiramatsu wrote:
(2013/06/25 17:15), zhangwei(Jovi) wrote:
There have no good reason to call free_trace_probe
every time when unregister_trace_probe return 0.
Move free_trace_probe into unregister_trace_probe,
make code simpler.
Sorry, nack. For the symmetrical
1 - 100 of 288 matches
Mail list logo
