Re: [RFC PATCH v3 01/19] skc: Add supplemental kernel cmdline support

2019-08-26 Thread Masami Hiramatsu
Hi Rob, Thank you for your comment! On Mon, 26 Aug 2019 08:27:48 -0500 Rob Herring wrote: > On Sun, Aug 25, 2019 at 10:15 PM Masami Hiramatsu wrote: > > > > Supplemental kernel command line (SKC) allows admin to pass a > > tree-structured supplemental kernel comma

[RFC PATCH v3 19/19] Documentation: tracing: Add boot-time tracing document

2019-08-25 Thread Masami Hiramatsu
Add a documentation about boot-time tracing options for SKC file. Signed-off-by: Masami Hiramatsu --- Documentation/trace/boottime-trace.rst | 185 1 file changed, 185 insertions(+) create mode 100644 Documentation/trace/boottime-trace.rst diff --git a

[RFC PATCH v3 18/19] tracing/boot: Add function-graph tracer options

2019-08-25 Thread Masami Hiramatsu
maximum depth of fgraph tracer. Note that these properties are available on ftrace global node only, because these filters are globally applied. Signed-off-by: Masami Hiramatsu --- kernel/trace/ftrace.c | 85 + kernel/trace/trace_boot.c | 71

[RFC PATCH v3 17/19] tracing/boot: Add function tracer filter options

2019-08-25 Thread Masami Hiramatsu
: Masami Hiramatsu --- kernel/trace/trace_boot.c | 40 1 file changed, 40 insertions(+) diff --git a/kernel/trace/trace_boot.c b/kernel/trace/trace_boot.c index 755a2040aebf..942ca8d3fcc8 100644 --- a/kernel/trace/trace_boot.c +++ b/kernel/trace/trace_boot.c

[RFC PATCH v3 16/19] tracing/boot: Add cpu_mask option support

2019-08-25 Thread Masami Hiramatsu
Add ftrace.cpumask option support for setting trace cpumask. - ftrace.[instance.INSTANCE.]cpumask = CPUMASK; Set the trace cpumask. Note that the CPUMASK should be a string which /tracing_cpumask can accepts. Signed-off-by: Masami Hiramatsu --- kernel/trace/trace.c | 41

[RFC PATCH v3 14/19] tracing/boot: Add synthetic event support

2019-08-25 Thread Masami Hiramatsu
ode requires "fields" string arraies, which defines the fields as same as tracing/synth_events interface. Signed-off-by: Masami Hiramatsu --- kernel/trace/trace_boot.c| 47 ++ kernel/trace/trace_events_hist.c |5 2 files changed,

[RFC PATCH v3 12/19] tracing/boot: Add per-event settings

2019-08-25 Thread Masami Hiramatsu
ilter = "pid < 128"; enable; } this will enable tracing "sched:sched_process_exec" event with "pid < 128" filter. Signed-off-by: Masami Hiramatsu --- kernel/trace/trace_boot.c | 60 +++ kernel/trace

[RFC PATCH v3 15/19] tracing/boot: Add instance node support

2019-08-25 Thread Masami Hiramatsu
Add instance node support to boottime tracing. User can set some options and event nodes under instance node. - ftrace.instance.INSTANCE[...]; Add new INSTANCE instance. Some options and event nodes are acceptable for instance node. Signed-off-by: Masami Hiramatsu --- kernel/trace

[RFC PATCH v3 11/19] tracing/boot: Add boot-time tracing by supplemental kernel cmdline

2019-08-25 Thread Masami Hiramatsu
at this is not replacing the kernel parameters, because this skc based setting is later than that. If you want to trace earlier boot events, you still need kernel parameters. Signed-off-by: Masami Hiramatsu --- kernel/trace/Kconfig |9 +++ kernel/trace/Makefile |1 kernel/trace/trace

[RFC PATCH v3 13/19] tracing/boot Add kprobe event support

2019-08-25 Thread Masami Hiramatsu
multiple probes on one event, but those must have same type of arguments. For example, ftrace.events.kprobes.myevent { probes = "vfs_read $arg1 $arg2"; enable; } This will add kprobes:myevent on vfs_read with the 1st and the 2nd arguments. Signed-off-by: Masam

[RFC PATCH v3 10/19] tracing: Add NULL trace-array check in print_synth_event()

2019-08-25 Thread Masami Hiramatsu
Add NULL trace-array check in print_synth_event(), because if we enable tp_printk option, iter->tr can be NULL. Signed-off-by: Masami Hiramatsu --- kernel/trace/trace_events_hist.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/trace_events_hist.c b/ker

[RFC PATCH v3 09/19] tracing: Accept different type for synthetic event fields

2019-08-25 Thread Masami Hiramatsu
Make the synthetic event accepts a different type field to record. However, the size and signed flag must be same. Signed-off-by: Masami Hiramatsu --- kernel/trace/trace_events_hist.c |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/kernel/trace/trace_events_hist.c

[RFC PATCH v3 07/19] tracing: Expose EXPORT_SYMBOL_GPL symbol

2019-08-25 Thread Masami Hiramatsu
Since ftrace_set_clr_event is already exported by EXPORT_SYMBOL_GPL, it should not be static. Signed-off-by: Masami Hiramatsu --- kernel/trace/trace_events.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c index

[RFC PATCH v3 08/19] tracing: kprobes: Register to dynevent earlier stage

2019-08-25 Thread Masami Hiramatsu
Register kprobe event to dynevent in subsys_initcall level. This will allow kernel to register new kprobe events in fs_initcall level via trace_run_command. Signed-off-by: Masami Hiramatsu --- kernel/trace/trace_kprobe.c | 19 +++ 1 file changed, 15 insertions(+), 4 deletions

[RFC PATCH v3 06/19] tracing: kprobes: Output kprobe event to printk buffer

2019-08-25 Thread Masami Hiramatsu
Since kprobe-events use event_trigger_unlock_commit_regs() directly, that events doesn't show up in printk buffer if "tp_printk" is set. Use trace_event_buffer_commit() in kprobe events so that it can invoke output_printk() as same as other trace events. Signed-off-by: M

[RFC PATCH v3 05/19] tracing: Apply soft-disabled and filter to tracepoints printk

2019-08-25 Thread Masami Hiramatsu
Apply soft-disabled and the filter rule of the trace events to the printk output of tracepoints (a.k.a. tp_printk kernel parameter) as same as trace buffer output. Signed-off-by: Masami Hiramatsu --- kernel/trace/trace.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/kernel/trace

[RFC PATCH v3 00/19] tracing: skc: Boot-time tracing and Supplemental Kernel Cmdline

2019-08-25 Thread Masami Hiramatsu
some loadable modules wants to use it. We have to keep at least query interface and tree nodes on memory. - As you can see, the EVENT.actions value is a bit ugly. Maybe we can introduce sub-nodes under action node, something like below. ftrace.event.initcall.initcall_finish.action.hist { keys = "func"; lat = "c

[RFC PATCH v3 04/19] Documentation: skc: Add a doc for supplemental kernel cmdline

2019-08-25 Thread Masami Hiramatsu
Add a documentation for supplemental kernel cmdline under admin-guide, since it is including the syntax of SKC file. Signed-off-by: Masami Hiramatsu --- Documentation/admin-guide/index.rst |1 Documentation/admin-guide/kernel-parameters.txt |1 Documentation/admin-guide

[RFC PATCH v3 03/19] skc: Add a boot setup routine from cmdline

2019-08-25 Thread Masami Hiramatsu
Add a boot setup routine from cmdline option "skc=ADDR,SIZE". Bootloader has to setup this cmdline option when it loads the skc file on memory. The ADDR must be a physical address. Signed-off-by: Masami Hiramatsu --- Documentation/admin-guide/kernel-parameters.txt |5 ++ i

[RFC PATCH v3 02/19] skc: Add /proc/sup_cmdline to show SKC key-value list

2019-08-25 Thread Masami Hiramatsu
Add /proc/sup_cmdline which shows the list of key-value pairs in SKC data. Since after boot, all SKC data and tree are removed, this interface just keep a copy of key-value pairs in text. Signed-off-by: Masami Hiramatsu --- MAINTAINERS |1 fs/proc/Makefile |1 fs/proc

[RFC PATCH v3 01/19] skc: Add supplemental kernel cmdline support

2019-08-25 Thread Masami Hiramatsu
= value2; It can fold same keys with braces, also you can write array data. For example, key { word1 { setting1 = data; setting2; } word2.array = "val1", "val2"; } User can access these key-value pair and tree structure via SKC APIs. Signed-off-

Re: [PATCH v5] arm64: implement KPROBES_ON_FTRACE

2019-08-23 Thread Masami Hiramatsu
; > after the patch: > > /sys/kernel/debug # cat kprobes/list > ff801009ff54 k _do_fork+0x4[DISABLED][FTRACE] > > Signed-off-by: Jisheng Zhang Looks good to me. Acked-by: Masami Hiramatsu Thank you, > --- > > KPROBES_ON_FTRACE avoids much of the overhea

Re: [PATCH v2 1/3] kprobes/x86: use instruction_pointer and instruction_pointer_set

2019-08-23 Thread Masami Hiramatsu
he processor software-breakpoint > > implementation. > > Per my understanding, the "+1" here means "+ one kprobe_opcode_t". No, that is the size of INT3. It just emulates the software trap on x86. Thank you, -- Masami Hiramatsu

Re: [PATCH v2 2/3] kprobes: adjust kprobe addr for KPROBES_ON_FTRACE

2019-08-20 Thread Masami Hiramatsu
+ p->addr = (kprobe_opcode_t *)addr; And again, please don't change the p->addr silently. Thank you, > #else/* !CONFIG_KPROBES_ON_FTRACE */ > return -EINVAL; > #endif > -- > 2.23.0.rc1 > -- Masami Hiramatsu

Re: [PATCH v2 1/3] kprobes/x86: use instruction_pointer and instruction_pointer_set

2019-08-20 Thread Masami Hiramatsu
e this patch itself is not related to the series, could you update the description and resend it as a single cleanup patch out of the series? Thank you! > > Thanks > > [1] > http://lists.infradead.org/pipermail/linux-arm-kernel/2019-August/674417.html -- Masami Hiramatsu

Re: [PATCH 1/6] docs: trace: fix a broken label

2019-06-19 Thread Masami Hiramatsu
oblem is quite simple: Sphinx wants a blank line after > references. > > Signed-off-by: Mauro Carvalho Chehab This also looks good to me. Acked-by: Masami Hiramatsu Thank you, > --- > Documentation/trace/kprobetrace.rst | 1 + > 1 file changed, 1 insertion(+) > > dif

Re: [PATCH 2/6] docs: trace: add a missing blank line

2019-06-19 Thread Masami Hiramatsu
On Tue, 18 Jun 2019 15:51:18 -0300 Mauro Carvalho Chehab wrote: > Sphinx expects a blank line after a literal block markup. > > Signed-off-by: Mauro Carvalho Chehab Looks good to me, thanks! Acked-by: Masami Hiramatsu > --- > Documentation/trace/kprobetrace.rst | 1 + >

Re: [PATCH 2/3] treewide: trivial: fix s/poped/popped/ typo

2019-06-07 Thread Masami Hiramatsu
On Wed, 5 Jun 2019 16:30:10 -0400 "George G. Davis" wrote: > Fix a couple of s/poped/popped/ typos. > > Cc: Jiri Kosina > Signed-off-by: George G. Davis Acked-by: Masami Hiramatsu Thanks, > --- > Documentation/arm/mem_alignment | 2 +- > arch/x86/kernel/kp

Re: [PATCH v2 2/2] tracing/kprobe: Add kprobe_event= boot parameter

2019-06-03 Thread Masami Hiramatsu
On Mon, 3 Jun 2019 20:52:38 +0900 Masami Hiramatsu wrote: > Hi Anders, > > Sorry for replying later. > > On Tue, 28 May 2019 15:39:15 +0200 > Anders Roxell wrote: > > > On Tue, 28 May 2019 at 14:36, Steven Rostedt wrote: > > > > > > On Tue, 2

Re: [PATCH v2 2/2] tracing/kprobe: Add kprobe_event= boot parameter

2019-06-03 Thread Masami Hiramatsu
Hi Anders, Sorry for replying later. On Tue, 28 May 2019 15:39:15 +0200 Anders Roxell wrote: > On Tue, 28 May 2019 at 14:36, Steven Rostedt wrote: > > > > On Tue, 28 May 2019 14:23:43 +0200 > > Anders Roxell wrote: > > > > > On Wed, 22 May 2019 at 1

[PATCH v2 2/2] tracing/kprobe: Add kprobe_event= boot parameter

2019-05-22 Thread Masami Hiramatsu
be on vfs_read with argument1 and 2, and enable the new event. Signed-off-by: Masami Hiramatsu --- Documentation/admin-guide/kernel-parameters.txt | 13 ++ Documentation/trace/kprobetrace.rst | 14 ++ kernel/trace/trace_kprobe.c | 54 +++

[PATCH v2 1/2] kprobes: Initialize kprobes at postcore_initcall

2019-05-22 Thread Masami Hiramatsu
initcall level. Signed-off-by: Masami Hiramatsu --- Changes in v2 - use postcore_initcall instead of subsys_initcall --- kernel/kprobes.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/kernel/kprobes.c b/kernel/kprobes.c index c83e54727131..5d51dd84b1a2 100644 --- a

[PATCH v2 0/2] Enable new kprobe event at boot

2019-05-22 Thread Masami Hiramatsu
s at this point. It is enough for tracing device driver initialization etc. Thank you, --- Masami Hiramatsu (2): kprobes: Initialize kprobes at postcore_initcall tracing/kprobe: Add kprobe_event= boot parameter Documentation/admin-guide/kernel-parameters.txt | 13 ++ Documenta

Re: [PATCH 0/2] Enable new kprobe event at boot

2019-05-22 Thread Masami Hiramatsu
On Wed, 22 May 2019 16:30:21 +0900 Masami Hiramatsu wrote: > On Wed, 22 May 2019 00:39:32 +0900 > Masami Hiramatsu wrote: > > > > Perhaps we could enable kprobes at early init? > > > > It should be possible, I will try to find what blocks it. I guess after we &

Re: [PATCH 0/2] Enable new kprobe event at boot

2019-05-22 Thread Masami Hiramatsu
On Wed, 22 May 2019 00:39:32 +0900 Masami Hiramatsu wrote: > > Perhaps we could enable kprobes at early init? > > It should be possible, I will try to find what blocks it. I guess after we > switch early_text_poke() to text_poke(), we can use kprobes on x86. But > for othe

Re: [PATCH 0/2] Enable new kprobe event at boot

2019-05-21 Thread Masami Hiramatsu
On Tue, 21 May 2019 09:33:17 -0400 Steven Rostedt wrote: > On Tue, 21 May 2019 16:56:16 +0900 > Masami Hiramatsu wrote: > > > Note that 'trace_event=' option enables trace event at very early > > timing, but the events added by 'kprobe_event=' are

[PATCH 2/2] tracing/kprobe: Add kprobe_event= boot parameter

2019-05-21 Thread Masami Hiramatsu
be on vfs_read with argument1 and 2, and enable the new event. Signed-off-by: Masami Hiramatsu --- Documentation/admin-guide/kernel-parameters.txt | 13 ++ Documentation/trace/kprobetrace.rst | 14 ++ kernel/trace/trace_kprobe.c | 54 +++

[PATCH 1/2] kprobes: Initialize kprobes at subsys_initcall

2019-05-21 Thread Masami Hiramatsu
Initialize kprobes at subsys_initcall stage instead of module_init since kprobes is not a module. This will allow ftrace kprobe event to add new events when it is initializing because ftrace kprobe event is initialized at fs_initcall. Signed-off-by: Masami Hiramatsu --- kernel/kprobes.c |2

[PATCH 0/2] Enable new kprobe event at boot

2019-05-21 Thread Masami Hiramatsu
that 'trace_event=' option enables trace event at very early timing, but the events added by 'kprobe_event=' are enabled right before enabling device drivers at this point. It is enough for tracing device driver initialization etc. Thank you, --- Masami Hiramatsu (2):

Re: [PATCH v3 1/2] Provide in-kernel headers for making it easy to extend the kernel

2019-02-28 Thread Masami Hiramatsu
Hi Joel, On Thu, 28 Feb 2019 22:26:11 -0500 Joel Fernandes wrote: > On Fri, Mar 01, 2019 at 11:28:26AM +0900, Masami Hiramatsu wrote: > > Hi Joel, > > Hi Masami, > > > On Thu, 28 Feb 2019 10:00:54 -0500 > > Joel Fernandes wrote: > > > > > > Hm

Re: [PATCH v3 1/2] Provide in-kernel headers for making it easy to extend the kernel

2019-02-28 Thread Masami Hiramatsu
; And this doesn't consume any disk-space. > > I felt using a compressed tar is really the easiest way because of all the > tools are already available. As I asked above, if the pure tarball is useful, you can simply ask vendors to put the header tarball on their vendor directory. I feel making it as a module is not a right way. > There isn't a compressed in-ram filesystem right > now that I'm aware off that can achieve the kind of high compression ratio > this patchset does. I think if linux can support something like tarfs(or compressed initramfs) in kernel, it gives linux an improvement not only a hack. :-) Thank you, -- Masami Hiramatsu

Re: [PATCH v3 1/2] Provide in-kernel headers for making it easy to extend the kernel

2019-02-28 Thread Masami Hiramatsu
compared with carrying kheaders.tar.gz. I think we would better have a psudo filesystem which can mount this compressed header file directly :) Then it becomes simpler, like modprobe headerfs mkdir $HOME/headers mount -t headerfs $HOME/headers And this doesn't consume any disk-space. Thank you, -- Masami Hiramatsu

Re: [PATCH v3 1/2] kretprobe: produce sane stack traces

2018-11-10 Thread Masami Hiramatsu
On Sat, 10 Nov 2018 02:06:29 +1100 Aleksa Sarai wrote: > On 2018-11-09, Masami Hiramatsu wrote: > > > diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h > > > index ee696efec99f..c4dfafd43e11 100644 > > > --- a/arch/x86/include/asm/ptrace.

Re: [PATCH v3 1/2] kretprobe: produce sane stack traces

2018-11-08 Thread Masami Hiramatsu
't _currently_ have a way of > dealing with that. If it's pointing to a real function, we can fix that > with unwind hints. As I replied, If the stackdump is called from kretprobe event, regs->ip always points trampoline function. Otherwise (maybe from kprobe event, or panic, BUG etc.) it always be the address which the event occurs. So fixing regs->ip is correct. Thank you, -- Masami Hiramatsu

Re: [PATCH v3 1/2] kretprobe: produce sane stack traces

2018-11-08 Thread Masami Hiramatsu
// the hash of tsk and current can be same. need_lock = true; } else // we should take a lock for tsk. need_lock = true; Thank you, > + > + hlist_for_each_entry(ri, head, hlist) { > + if (ri->task != current) > + continue; > + if (ri->ret_addr == (kprobe_opcode_t *) &kretprobe_trampoline) > + continue; > + if (ri->ret_addrp == (kprobe_opcode_t **) retp) { > + ret = (unsigned long) ri->ret_addr; > + goto out; > + } > + } > + > +out: > + if (need_lock) > + kretprobe_hash_unlock(tsk, &flags); > + return ret; > +} > +NOKPROBE_SYMBOL(kretprobe_ret_addr); > + > bool __weak arch_kprobe_on_func_entry(unsigned long offset) > { > return !offset; > @@ -2005,6 +2054,12 @@ static int pre_handler_kretprobe(struct kprobe *p, > struct pt_regs *regs) > } > NOKPROBE_SYMBOL(pre_handler_kretprobe); > > +unsigned long kretprobe_ret_addr(struct task_struct *tsk, unsigned long ret, > + unsigned long *retp) > +{ > + return ret; > +} > +NOKPROBE_SYMBOL(kretprobe_ret_addr); > #endif /* CONFIG_KRETPROBES */ > > /* Set the kprobe gone and remove its instruction buffer. */ > -- > 2.19.1 -- Masami Hiramatsu

Re: [PATCH v3 1/2] kretprobe: produce sane stack traces

2018-11-03 Thread Masami Hiramatsu
On Sat, 3 Nov 2018 13:30:21 -0400 Steven Rostedt wrote: > On Sun, 4 Nov 2018 01:34:30 +0900 > Masami Hiramatsu wrote: > > > > > I was thinking of a bitmask that represents the handlers, and use that > > > to map which handler gets called for which shadow ent

Re: [PATCH v3 1/2] kretprobe: produce sane stack traces

2018-11-03 Thread Masami Hiramatsu
On Sat, 3 Nov 2018 09:13:41 -0400 Steven Rostedt wrote: > On Sat, 3 Nov 2018 22:00:12 +0900 > Masami Hiramatsu wrote: > > > On Fri, 2 Nov 2018 12:13:07 -0400 > > Steven Rostedt wrote: > > > > > > Because that means if function graph tracer is active, t

Re: [PATCH v3 1/2] kretprobe: produce sane stack traces

2018-11-03 Thread Masami Hiramatsu
is unregistered, it the corresponding bits that represent > it are cleared, and it the return callback will not be called. But the > tasks being traced will still have their shadow stack to allow it to > get back to normal. > > I'll hopefully have a prototype ready by plumbers. > > And this too will require each architecture to probably change. As a > side project to this, I'm going to try to consolidate the function > graph code among all the architectures as well. Not an easy task. > > -- Steve -- Masami Hiramatsu

Re: [PATCH v3 1/2] kretprobe: produce sane stack traces

2018-11-03 Thread Masami Hiramatsu
if you're interested. > > > > I'd like to have that, but it still requires some work. But I'd just > the truly architecture dependent code be in the architecture (basically > the asm code), and have the ability to move most of the duplicate code > out of the archs. I will also do that for kretprobe handlers. Thank you, -- Masami Hiramatsu

Re: [PATCH v3 1/2] kretprobe: produce sane stack traces

2018-11-03 Thread Masami Hiramatsu
On Fri, 2 Nov 2018 15:37:33 +1100 Aleksa Sarai wrote: > On 2018-11-02, Masami Hiramatsu wrote: > > On Fri, 2 Nov 2018 08:13:43 +1100 > > Aleksa Sarai wrote: > > > > > On 2018-11-02, Masami Hiramatsu wrote: > > > > Please split the test case as

Re: [PATCH v3 1/2] kretprobe: produce sane stack traces

2018-11-01 Thread Masami Hiramatsu
On Fri, 2 Nov 2018 08:13:43 +1100 Aleksa Sarai wrote: > On 2018-11-02, Masami Hiramatsu wrote: > > Please split the test case as an independent patch. > > Will do. Should the Documentation/ change also be a separate patch? I think the Documentation change can be coupled with

Re: [PATCH v3 1/2] kretprobe: produce sane stack traces

2018-11-01 Thread Masami Hiramatsu
kprobe/enable > +( echo "forked") > +echo 0 > events/kprobes/teststackprobe/enable > + > +# Make sure we don't see kretprobe_trampoline and we see _do_fork. > +! grep 'kretprobe' trace > +grep '_do_fork' trace > + > +echo '-:teststackprobe' >> kprobe_events > +clear_trace > +test -d events/kprobes/teststackprobe && exit_fail || exit_pass > -- > 2.19.1 > -- Masami Hiramatsu

Re: [PATCH v3 6/9] trace_uprobe: Support SDT markers having reference count (semaphore)

2018-05-07 Thread Masami Hiramatsu
d. Naveen, could you update it according to Oleg's comment, and resend it? > > Also, I'll add a check in sdt_update_ref_ctr() to make sure reference > counter never goes to negative incase increment fails but decrement > succeeds. OTOH, if increment succeeds but decrement f

Re: [PATCH v3 6/9] trace_uprobe: Support SDT markers having reference count (semaphore)

2018-05-03 Thread Masami Hiramatsu
down_write(&info->mm->mmap_sem); > + > + if (sdt_find_vma(tu, info->mm, info->vaddr)) > + sdt_update_ref_ctr(info->mm, info->vaddr, -1); Ditto. Thank you, > + > + up_write(&info->mm->mmap_sem); > +

Re: [PATCH v3 8/9] trace_uprobe/sdt: Document about reference counter

2018-05-03 Thread Masami Hiramatsu
tical to semaphore in Userspace Statically Defined > Tracepoints (USDT). > > Document usage of reference counter. > > Signed-off-by: Ravi Bangoria Looks good to me. Acked-by: Masami Hiramatsu Thanks! > --- > Documentation/trace/uprobetracer.txt | 16 +

Re: [PATCH v3 9/9] perf probe: Support SDT markers having reference counter (semaphore)

2018-05-03 Thread Masami Hiramatsu
ce counter stats for '/tmp/tick': > 3 sdt_tick:loop2 >2.561851452 seconds time elapsed > > Signed-off-by: Ravi Bangoria Looks good to me. Acked-by: Masami Hiramatsu Thanks! > --- > tools/perf/util/probe-event.c | 39 +

Re: [PATCH v2 9/9] perf probe: Support SDT markers having reference counter (semaphore)

2018-04-09 Thread Masami Hiramatsu
On Mon, 9 Apr 2018 13:59:16 +0530 Ravi Bangoria wrote: > Hi Masami, > > On 04/09/2018 12:58 PM, Masami Hiramatsu wrote: > > Hi Ravi, > > > > On Wed, 4 Apr 2018 14:01:10 +0530 > > Ravi Bangoria wrote: > > > >> @@ -2054,15 +2060,2

Re: [PATCH v2 9/9] perf probe: Support SDT markers having reference counter (semaphore)

2018-04-09 Thread Masami Hiramatsu
; > - int i, args_count; > + int i, args_count, err; > + unsigned long long ref_ctr_offset; > > if (strbuf_init(&buf, 32) < 0) > return NULL; > > - if (strbuf_addf(&buf, "p:%s/%s %s:0x%llx", > -

Re: [PATCH 8/8] trace_uprobe/sdt: Document about reference counter

2018-03-16 Thread Masami Hiramatsu
On Fri, 16 Mar 2018 15:12:38 +0530 Ravi Bangoria wrote: > On 03/15/2018 06:17 PM, Masami Hiramatsu wrote: > > Hi Ravi, > > > > On Wed, 14 Mar 2018 20:52:59 +0530 > > Ravi Bangoria wrote: > > > >> On 03/14/2018 07:20 PM, Masami Hiramatsu wrote: > >

Re: [PATCH 8/8] trace_uprobe/sdt: Document about reference counter

2018-03-15 Thread Masami Hiramatsu
Hi Ravi, On Wed, 14 Mar 2018 20:52:59 +0530 Ravi Bangoria wrote: > On 03/14/2018 07:20 PM, Masami Hiramatsu wrote: > > On Tue, 13 Mar 2018 18:26:03 +0530 > > Ravi Bangoria wrote: > > > >> No functionality changes. > > Please consider to describe what is this

Re: [PATCH 6/8] trace_uprobe/sdt: Fix multiple update of same reference counter

2018-03-14 Thread Masami Hiramatsu
probe_lock); > } > @@ -1038,7 +1130,11 @@ static void sdt_decrement_ref_ctr(struct trace_uprobe > *tu) > if (IS_ERR(info)) > goto out; > > + down_write(&tu->sml_rw_sem); > while (info) { > + if (!sdt_check_mm_list(tu, info->mm)) > + goto cont; > + > down_write(&info->mm->mmap_sem); > > vma = sdt_find_vma(info->mm, tu); > @@ -1046,9 +1142,14 @@ static void sdt_decrement_ref_ctr(struct trace_uprobe > *tu) > sdt_update_ref_ctr(info->mm, vaddr, -1); > > up_write(&info->mm->mmap_sem); > + sdt_del_mm_list(tu, info->mm); > + > +cont: > mmput(info->mm); > info = uprobe_free_map_info(info); > } > + sdt_flush_mm_list(tu); > + up_write(&tu->sml_rw_sem); > > out: > uprobe_end_dup_mmap(); > -- > 1.8.3.1 > -- Masami Hiramatsu -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 7/8] perf probe: Support SDT markers having reference counter (semaphore)

2018-03-14 Thread Masami Hiramatsu
(shdr.sh_offset) { > + if (tmp->bit32) > + tmp->addr.a32[2] -= (shdr.sh_addr - > shdr.sh_offset); > + else > + tmp->addr.a64[2] -= (shdr.sh_addr - > shdr.sh_offset); Here we should use enum above too. Thank you, > + } > + } > + > list_add_tail(&tmp->note_list, sdt_notes); > return 0; > > diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h > index 70c16741..ad0c4f2 100644 > --- a/tools/perf/util/symbol.h > +++ b/tools/perf/util/symbol.h > @@ -384,6 +384,7 @@ struct sdt_note { > int cleanup_sdt_note_list(struct list_head *sdt_notes); > int sdt_notes__get_count(struct list_head *start); > > +#define SDT_PROBES_SCN ".probes" > #define SDT_BASE_SCN ".stapsdt.base" > #define SDT_NOTE_SCN ".note.stapsdt" > #define SDT_NOTE_TYPE 3 > -- > 1.8.3.1 > -- Masami Hiramatsu -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 8/8] trace_uprobe/sdt: Document about reference counter

2018-03-14 Thread Masami Hiramatsu
> @@ -4604,7 +4604,7 @@ static int tracing_trace_options_open(struct inode > *inode, struct file *file) >"place (kretprobe): [:][+]|\n" > #endif > #ifdef CONFIG_UPROBE_EVENTS > - "\t place: :\n" > + " place (uprobe): :[(ref_ctr_offset)]\

Re: [PATCH 5/8] trace_uprobe: Support SDT markers having reference count (semaphore)

2018-03-14 Thread Masami Hiramatsu
uprobe_end_dup_mmap(); > +} > + > typedef bool (*filter_func_t)(struct uprobe_consumer *self, > enum uprobe_filter_ctx ctx, > struct mm_struct *mm); > @@ -939,6 +1099,9 @@ typedef bool (*filter_func_t)(struct uprobe_consumer > *self, >

Re: [PATCH 11/30] kprobes.txt: standardize document format

2017-05-19 Thread Masami Hiramatsu
lines where needed. OK, it seems good to me. Acked-by: Masami Hiramatsu By the way, there are some words which referes other section in this document, should it also be updated according to Sphinx format? e.g. [snip] > @@ -53,7 +59,8 @@ a post_handler, and how to use the maxactive and nmissed

Re: [PATCH v3] tracing/kprobes: expose maxactive for kretprobe in kprobe_events

2017-04-04 Thread Masami Hiramatsu
[PASS] > > [6] Kretprobe dynamic event with arguments [PASS] > > [7] Kretprobe dynamic event with maxactive [PASS] > > > > # of passed: 7 > > # of failed: 0 > > # of unresolved: 0 > > # of untested: 0 > > # of unsupported: 0 > > # of xfailed

Re: [PATCH v2] tracing/kprobes: expose maxactive for kretprobe in kprobe_events

2017-03-31 Thread Masami Hiramatsu
event with maxactive[PASS] > > > > > > # of passed: 7 > > > # of failed: 0 > > > # of unresolved: 0 > > > # of untested: 0 > > > # of unsupported: 0 > > > # of xfailed: 0 > > > # of undefined(test bug): 0 > > > > B

Re: [RFC PATCH tip/master 2/3] kprobes: Allocate kretprobe instance if its free list is empty

2017-03-30 Thread Masami Hiramatsu
On Thu, 30 Mar 2017 08:53:32 +0200 Ingo Molnar wrote: > > * Masami Hiramatsu wrote: > > > > So this is something I missed while the original code was merged, but the > > > concept > > > looks a bit weird: why do we do any "allocation" while a ha

Re: [RFC PATCH tip/master 2/3] kprobes: Allocate kretprobe instance if its free list is empty

2017-03-29 Thread Masami Hiramatsu
On Wed, 29 Mar 2017 10:18:48 -0700 Josh Stone wrote: > On 03/29/2017 01:25 AM, Masami Hiramatsu wrote: > > On Wed, 29 Mar 2017 08:30:05 +0200 > > Ingo Molnar wrote: > >> > >> * Masami Hiramatsu wrote: > >> > >>> @@ -1824,6 +1823,30 @@ void

Re: [RFC PATCH tip/master 2/3] kprobes: Allocate kretprobe instance if its free list is empty

2017-03-29 Thread Masami Hiramatsu
On Wed, 29 Mar 2017 08:30:05 +0200 Ingo Molnar wrote: > > * Masami Hiramatsu wrote: > > > @@ -1824,6 +1823,30 @@ void unregister_jprobes(struct jprobe **jps, int num) > > EXPORT_SYMBOL_GPL(unregister_jprobes); > > > > #ifdef CONFIG_KRETPROBES > > +

[RFC PATCH tip/master 3/3] kprobes: Limit kretprobe maximum instances

2017-03-28 Thread Masami Hiramatsu
Limit kretprobe maximum instance up to MAXACTIVE_ALLOC. Without this limit, kretprobe user can specify huge number (e.g. forget to zero-fill struct kretprobe) to maxactive and may cause out-of-memory. Signed-off-by: Masami Hiramatsu --- kernel/kprobes.c |3 +++ 1 file changed, 3 insertions

[RFC PATCH tip/master 2/3] kprobes: Allocate kretprobe instance if its free list is empty

2017-03-28 Thread Masami Hiramatsu
(but nmissed count is incremented), if someone probe functions on the memory allocation path. Signed-off-by: Masami Hiramatsu --- Documentation/kprobes.txt | 25 +++-- include/linux/kprobes.h |2 ++ kernel/kprobes.c | 41 +--

[RFC PATCH tip/master 1/3] trace: kprobes: Show sum of probe/retprobe nmissed count

2017-03-28 Thread Masami Hiramatsu
Show sum of probe and retprobe nmissed count in kprobe_profile, since retprobe can be missed even if the kprobe itself succeeeded. This explains user why their return probe didn't hit sometimes. Signed-off-by: Masami Hiramatsu --- kernel/trace/trace_kprobe.c |2 +- 1 file chang

[RFC PATCH tip/master 0/3] kprobes: tracing: kretprobe_instance dynamic allocation

2017-03-28 Thread Masami Hiramatsu
er limiation in trace_kprobe.c too. Thank you, --- Masami Hiramatsu (3): trace: kprobes: Show sum of probe/retprobe nmissed count kprobes: Allocate kretprobe instance if its free list is empty kprobes: Limit kretprobe maximum instances Documentation/kprob

Re: [PATCH v1] tracing/kprobes: expose maxactive for kretprobe in kprobe_events

2017-03-28 Thread Masami Hiramatsu
On Tue, 28 Mar 2017 18:08:16 +0200 Alban Crequy wrote: > Thanks for the review, > > On Tue, Mar 28, 2017 at 5:23 PM, Masami Hiramatsu wrote: > > On Tue, 28 Mar 2017 15:52:22 +0200 > > Alban Crequy wrote: > > > >> When a kretprobe is installed on a

Re: [PATCH v1] tracing/kprobes: expose maxactive for kretprobe in kprobe_events

2017-03-28 Thread Masami Hiramatsu
On Tue, 28 Mar 2017 11:34:07 -0400 Steven Rostedt wrote: > On Wed, 29 Mar 2017 00:23:35 +0900 > Masami Hiramatsu wrote: > > > > @@ -598,8 +601,10 @@ static int create_trace_kprobe(int argc, char **argv) > > > { > > > /* > > >* Argument syn

Re: [PATCH v1] tracing/kprobes: expose maxactive for kretprobe in kprobe_events

2017-03-28 Thread Masami Hiramatsu
18,8 +742,8 @@ static int create_trace_kprobe(int argc, char **argv) >is_return ? 'r' : 'p', addr); > event = buf; > } > - tk = alloc_trace_kprobe(group, event, addr, symbol, offset, argc, > -is_return); > + tk = alloc_trace_kprobe(group, event, addr, symbol, offset, maxactive, > +argc, is_return); > if (IS_ERR(tk)) { > pr_info("Failed to allocate trace_probe.(%d)\n", > (int)PTR_ERR(tk)); > -- > 2.7.4 > -- Masami Hiramatsu -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation: kprobes: Document jprobes stack copying limitations

2016-08-12 Thread Masami Hiramatsu
On Fri, 12 Aug 2016 16:24:44 -0400 David Long wrote: > From: "David A. Long" > > Some architectures (i.e.: sparc64 and arm64) make reasonable partial stack > duplication for jprobes problematic. Document this. > > Signed-off-by: David A. Long Looks good to me.