[PATCH v12 03/19] function_graph: Pass ftrace_regs to entryfunc

2024-07-03 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Pass ftrace_regs to the fgraph_ops::entryfunc(). If ftrace_regs is not available, it passes a NULL instead. User callback function can access some registers (including return address) via this ftrace_regs. Signed-off-by: Masami Hiramatsu (Google) --- Changes in

[PATCH v12 02/19] tracing: Rename ftrace_regs_return_value to ftrace_regs_get_return_value

2024-07-03 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Rename ftrace_regs_return_value to ftrace_regs_get_return_value as same as other ftrace_regs_get/set_* APIs. Signed-off-by: Masami Hiramatsu (Google) Acked-by: Mark Rutland --- Changes in v6: - Moved to top of the series. Changes in v3: - Newly added

[PATCH v12 01/19] tracing: Add a comment about ftrace_regs definition

2024-07-03 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) To clarify what will be expected on ftrace_regs, add a comment to the architecture independent definition of the ftrace_regs. Signed-off-by: Masami Hiramatsu (Google) Acked-by: Mark Rutland --- Changes in v8: - Update that the saved registers depends on the

[PATCH v12 00/19] tracing: fprobe: function_graph: Multi-function graph and fprobe on fgraph

2024-07-03 Thread Masami Hiramatsu (Google)
wnload This series can be applied against the ftrace/for-next branch in linux-trace tree. This series can also be found below branch. https://git.kernel.org/pub/scm/linux/kernel/git/mhiramat/linux.git/log/?h=topic/fprobe-on-fgraph Thank you, --- Masami Hiramatsu (Google) (19):

Re: [PATCHv2 bpf-next 1/9] uprobe: Add support for session consumer

2024-07-02 Thread Google
44 > --- a/kernel/trace/trace_uprobe.c > +++ b/kernel/trace/trace_uprobe.c > @@ -88,9 +88,11 @@ static struct trace_uprobe *to_trace_uprobe(struct > dyn_event *ev) > static int register_uprobe_event(struct trace_uprobe *tu); > static int unregister_uprobe_event(struct trace_uprobe *tu); > > -static int uprobe_dispatcher(struct uprobe_consumer *con, struct pt_regs > *regs); > +static int uprobe_dispatcher(struct uprobe_consumer *con, struct pt_regs > *regs, > + __u64 *data); > static int uretprobe_dispatcher(struct uprobe_consumer *con, > - unsigned long func, struct pt_regs *regs); > + unsigned long func, struct pt_regs *regs, > + __u64 *data); > > #ifdef CONFIG_STACK_GROWSUP > static unsigned long adjust_stack_addr(unsigned long addr, unsigned int n) > @@ -1504,7 +1506,8 @@ trace_uprobe_register(struct trace_event_call *event, > enum trace_reg type, > } > } > > -static int uprobe_dispatcher(struct uprobe_consumer *con, struct pt_regs > *regs) > +static int uprobe_dispatcher(struct uprobe_consumer *con, struct pt_regs > *regs, > + __u64 *data) > { > struct trace_uprobe *tu; > struct uprobe_dispatch_data udd; > @@ -1534,7 +1537,8 @@ static int uprobe_dispatcher(struct uprobe_consumer > *con, struct pt_regs *regs) > } > > static int uretprobe_dispatcher(struct uprobe_consumer *con, > - unsigned long func, struct pt_regs *regs) > + unsigned long func, struct pt_regs *regs, > + __u64 *data) > { > struct trace_uprobe *tu; > struct uprobe_dispatch_data udd; > -- > 2.45.2 > -- Masami Hiramatsu (Google)

Re: [PATCH] LoongArch: uprobes: make UPROBE_SWBP_INSN/UPROBE_XOLBP_INSN constant

2024-06-27 Thread Google
e, but > perhaps KPROBE_BP_INSN and KPROBE_SSTEPBP_INSN should be redefined the > same way for micro-optimization. In this case __emit_break() should be > probably moved into arch/loongarch/include/asm/inst.h. That idea sounds good to me too. If it is good to loongarch maintainers, (e.g. breakpoint instruction is stable), it is better to define in asm/insn.h. Thank you, > > Oleg. > > -- Masami Hiramatsu (Google)

Re: [PATCH] uprobe: Do not use UPROBE_SWBP_INSN as static initializer

2024-06-27 Thread Google
/kernel/uprobes.c > > > +++ x/arch/loongarch/kernel/uprobes.c > > > @@ -7,6 +7,13 @@ > > > > > > #define UPROBE_TRAP_NR UINT_MAX > > > > > > +static __init int __ck_insn(void) > > > +{ > > > + BUG_ON(UPROBE_SWBP_INSN != larch_insn_gen_break(BRK_UPROBE_BP)); > > > + return 0; > > > +} > > > +late_initcall(__ck_insn); > > > + > > > int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe, > > >struct mm_struct *mm, unsigned long addr) > > > { > > > -- Masami Hiramatsu (Google)

Re: [PATCH v2] filemap: add trace events for get_pages, map_pages, and fault

2024-06-26 Thread Google
duction in the pack file > by 7.3% - 20% on ChromeOS varying by device. > This looks good to me from the trace-event point of view. Reviewed-by: Masami Hiramatsu (Google) Thanks! > Signed-off-by: Takaya Saeki > --- > Changelog between v2 and v1 > - Fix a file offset type us

Re: [PATCH v11 00/18] tracing: fprobe: function_graph: Multi-function graph and fprobe on fgraph

2024-06-24 Thread Google
On Mon, 17 Jun 2024 10:46:28 +0900 "Masami Hiramatsu (Google)" wrote: > Hi, > > Here is the 11th version of the series to re-implement the fprobe on > function-graph tracer. The previous version is; > > https://lore.kernel.org/all/171509088006.162236.722732

Re: [PATCH v2] KUnit: add missing MODULE_DESCRIPTION() macros for lib/test_*.ko

2024-06-20 Thread Google
odpost: missing MODULE_DESCRIPTION() in lib/test_bits.o > > Add the missing invocations of the MODULE_DESCRIPTION() macro. > > Signed-off-by: Jeff Johnson > --- > Changes in v2: > - Updated the description of lib/test_kprobes.c per Masami Confirmed. Thanks! Reviewed-by: Mas

Re: [PATCH] trace: riscv: Remove deprecated kprobe on ftrace support

2024-06-19 Thread Google
and > KPROBES_ON_FTRACE will be supplanted by FPROBES. So remove the deprecated > kprobe on ftrace support, which is misunderstood. > > Signed-off-by: Jinjie Ruan No problem, Now we have fprobe instead. Anyway, this looks good to me. Acked-by: Masami Hiramatsu (Google) Tha

Re: [PATCH] fgraph: Use str_plural() in test_graph_storage_single()

2024-06-19 Thread Google
ugzilla.openanolis.cn/show_bug.cgi?id=9349 > Signed-off-by: Jiapeng Chong Thanks, this looks good to me. Acked-by: Masami Hiramatsu (Google) > --- > kernel/trace/trace_selftest.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/trace/trace_sel

[PATCH v11 18/18] fgraph: Skip recording calltime/rettime if it is not nneeded

2024-06-16 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Skip recording calltime and rettime if the fgraph_ops does not need it. This is a kind of performance optimization for fprobe. Since the fprobe user does not use these entries, recording timestamp in fgraph is just a overhead (e.g. eBPF, ftrace). So introduce the

[PATCH v11 17/18] Documentation: probes: Update fprobe on function-graph tracer

2024-06-16 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Update fprobe documentation for the new fprobe on function-graph tracer. This includes some bahvior changes and pt_regs to ftrace_regs interface change. Signed-off-by: Masami Hiramatsu (Google) --- Changes in v2: - Update @fregs parameter explanation

[PATCH v11 16/18] selftests/ftrace: Add a test case for repeating register/unregister fprobe

2024-06-16 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) This test case repeats define and undefine the fprobe dynamic event to ensure that the fprobe does not cause any issue with such operations. Signed-off-by: Masami Hiramatsu (Google) --- .../test.d/dynevent/add_remove_fprobe_repeat.tc| 19

[PATCH v11 15/18] selftests: ftrace: Remove obsolate maxactive syntax check

2024-06-16 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Since the fprobe event does not support maxactive anymore, stop testing the maxactive syntax error checking. Signed-off-by: Masami Hiramatsu (Google) --- .../ftrace/test.d/dynevent/fprobe_syntax_errors.tc |4 +--- 1 file changed, 1 insertion(+), 3 deletions

[PATCH v11 14/18] tracing/fprobe: Remove nr_maxactive from fprobe

2024-06-16 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Remove depercated fprobe::nr_maxactive. This involves fprobe events to rejects the maxactive number. Signed-off-by: Masami Hiramatsu (Google) --- Changes in v2: - Newly added. --- include/linux/fprobe.h |2 -- kernel/trace/trace_fprobe.c | 44

[PATCH v11 13/18] fprobe: Rewrite fprobe on function-graph tracer

2024-06-16 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Rewrite fprobe implementation on function-graph tracer. Major API changes are: - 'nr_maxactive' field is deprecated. - This depends on CONFIG_DYNAMIC_FTRACE_WITH_ARGS or !CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS, and CONFIG_HAVE_FUNCTION_GRAPH

[PATCH v11 12/18] ftrace: Add CONFIG_HAVE_FTRACE_GRAPH_FUNC

2024-06-16 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Add CONFIG_HAVE_FTRACE_GRAPH_FUNC kconfig in addition to ftrace_graph_func macro check. This is for the other feature (e.g. FPROBE) which requires to access ftrace_regs from fgraph_ops::entryfunc() can avoid compiling if the fgraph can not pass the valid

[PATCH v11 11/18] bpf: Enable kprobe_multi feature if CONFIG_FPROBE is enabled

2024-06-16 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Enable kprobe_multi feature if CONFIG_FPROBE is enabled. The pt_regs is converted from ftrace_regs by ftrace_partial_regs(), thus some registers may always returns 0. But it should be enough for function entry (access arguments) and exit (access return value

[PATCH v11 10/18] tracing/fprobe: Enable fprobe events with CONFIG_DYNAMIC_FTRACE_WITH_ARGS

2024-06-16 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Allow fprobe events to be enabled with CONFIG_DYNAMIC_FTRACE_WITH_ARGS. With this change, fprobe events mostly use ftrace_regs instead of pt_regs. Note that if the arch doesn't enable HAVE_PT_REGS_COMPAT_FTRACE_REGS, fprobe events will not be able to be used

[PATCH v11 09/18] tracing: Add ftrace_fill_perf_regs() for perf event

2024-06-16 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Add ftrace_fill_perf_regs() which should be compatible with the perf_fetch_caller_regs(). In other words, the pt_regs returned from the ftrace_fill_perf_regs() must satisfy 'user_mode(regs) == false' and can be used for stack tracing. Signed-off-

[PATCH v11 08/18] tracing: Add ftrace_partial_regs() for converting ftrace_regs to pt_regs

2024-06-16 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Add ftrace_partial_regs() which converts the ftrace_regs to pt_regs. This is for the eBPF which needs this to keep the same pt_regs interface to access registers. Thus when replacing the pt_regs with ftrace_regs in fprobes (which is used by kprobe_multi eBPF event

[PATCH v11 07/18] fprobe: Use ftrace_regs in fprobe exit handler

2024-06-16 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Change the fprobe exit handler to use ftrace_regs structure instead of pt_regs. This also introduce HAVE_PT_REGS_TO_FTRACE_REGS_CAST which means the ftrace_regs's memory layout is equal to the pt_regs so that those are able to cast. Fprobe introduces

[PATCH v11 06/18] fprobe: Use ftrace_regs in fprobe entry handler

2024-06-16 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) This allows fprobes to be available with CONFIG_DYNAMIC_FTRACE_WITH_ARGS instead of CONFIG_DYNAMIC_FTRACE_WITH_REGS, then we can enable fprobe on arm64. Signed-off-by: Masami Hiramatsu (Google) Acked-by: Florent Revest --- Changes in v6: - Keep using

[PATCH v11 05/18] function_graph: Pass ftrace_regs to retfunc

2024-06-16 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Pass ftrace_regs to the fgraph_ops::retfunc(). If ftrace_regs is not available, it passes a NULL instead. User callback function can access some registers (including return address) via this ftrace_regs. Signed-off-by: Masami Hiramatsu (Google) --- Changes in

[PATCH v11 04/18] function_graph: Replace fgraph_ret_regs with ftrace_regs

2024-06-16 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Use ftrace_regs instead of fgraph_ret_regs for tracing return value on function_graph tracer because of simplifying the callback interface. The CONFIG_HAVE_FUNCTION_GRAPH_RETVAL is also replaced by CONFIG_HAVE_FUNCTION_GRAPH_FREGS. Signed-off-by: Masami

[PATCH v11 03/18] function_graph: Pass ftrace_regs to entryfunc

2024-06-16 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Pass ftrace_regs to the fgraph_ops::entryfunc(). If ftrace_regs is not available, it passes a NULL instead. User callback function can access some registers (including return address) via this ftrace_regs. Signed-off-by: Masami Hiramatsu (Google) --- Changes in

[PATCH v11 02/18] tracing: Rename ftrace_regs_return_value to ftrace_regs_get_return_value

2024-06-16 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Rename ftrace_regs_return_value to ftrace_regs_get_return_value as same as other ftrace_regs_get/set_* APIs. Signed-off-by: Masami Hiramatsu (Google) Acked-by: Mark Rutland --- Changes in v6: - Moved to top of the series. Changes in v3: - Newly added

[PATCH v11 01/18] tracing: Add a comment about ftrace_regs definition

2024-06-16 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) To clarify what will be expected on ftrace_regs, add a comment to the architecture independent definition of the ftrace_regs. Signed-off-by: Masami Hiramatsu (Google) Acked-by: Mark Rutland --- Changes in v8: - Update that the saved registers depends on the

[PATCH v11 00/18] tracing: fprobe: function_graph: Multi-function graph and fprobe on fgraph

2024-06-16 Thread Masami Hiramatsu (Google)
plied against the ftrace/for-next branch in linux-trace tree. This series can also be found below branch. https://git.kernel.org/pub/scm/linux/kernel/git/mhiramat/linux.git/log/?h=topic/fprobe-on-fgraph Thank you, --- Masami Hiramatsu (Google) (18): tracing: Add a comment about f

Re: [PATCH] bpf/selftests: Fix __NR_uretprobe in uprobe_syscall test

2024-06-15 Thread Google
On Sun, 16 Jun 2024 00:19:20 +0900 Masami Hiramatsu (Google) wrote: > On Fri, 14 Jun 2024 12:15:09 +0200 > Jiri Olsa wrote: > > > Fixing the __NR_uretprobe number in uprobe_syscall test, > > because it changed due to merge conflict. > > > > Ah, it is not

Re: [PATCH] bpf/selftests: Fix __NR_uretprobe in uprobe_syscall test

2024-06-15 Thread Google
; -#define __NR_uretprobe 463 > +#define __NR_uretprobe 467 > #endif > > __naked unsigned long uretprobe_syscall_call_1(void) > -- > 2.45.1 > -- Masami Hiramatsu (Google)

Re: [PATCH] function_graph: Add READ_ONCE() when accessing fgraph_array[]

2024-06-13 Thread Google
On Thu, 13 Jun 2024 09:52:23 -0400 Steven Rostedt wrote: > From: "Steven Rostedt (Google)" > > In function_graph_enter() there's a loop that looks at fgraph_array[] > elements which are fgraph_ops. It first tests if it is a fgraph_stub op, > and if so skips it, a

Re: [PATCH v3 3/3] tracing/kprobe: Remove cleanup code unrelated to selftest

2024-06-11 Thread Google
On Tue, 11 Jun 2024 10:25:00 -0400 Steven Rostedt wrote: > On Tue, 11 Jun 2024 22:30:56 +0900 > "Masami Hiramatsu (Google)" wrote: > > > From: Masami Hiramatsu (Google) > > > > This cleanup all kprobe events code is not related to the selftest >

Re: [PATCHv8 bpf-next 0/9] uprobe: uretprobe speed up

2024-06-11 Thread Google
sertions(+), 10 deletions(-) > create mode 100644 tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c > create mode 100644 tools/testing/selftests/bpf/progs/uprobe_syscall.c > create mode 100644 > tools/testing/selftests/bpf/progs/uprobe_syscall_executed.c > > Jiri Olsa (1): > man2: Add uretprobe syscall page > > man/man2/uretprobe.2 | 56 > > 1 file changed, 56 insertions(+) > create mode 100644 man/man2/uretprobe.2 -- Masami Hiramatsu (Google)

Re: [PATCHv8 9/9] man2: Add uretprobe syscall page

2024-06-11 Thread Google
On Tue, 11 Jun 2024 13:21:58 +0200 Jiri Olsa wrote: > Adding man page for new uretprobe syscall. > > Acked-by: Andrii Nakryiko > Reviewed-by: Alejandro Colomar > Signed-off-by: Jiri Olsa This looks good to me. Reviewed-by: Masami Hiramatsu (Google) And this needs to be

Re: [PATCHv7 bpf-next 0/9] uprobe: uretprobe speed up

2024-06-11 Thread Google
> > Acked-by: Andrii Nakryiko Thanks! let me pick the next version. -- Masami Hiramatsu (Google)

[PATCH v3 3/3] tracing/kprobe: Remove cleanup code unrelated to selftest

2024-06-11 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) This cleanup all kprobe events code is not related to the selftest itself, and it can fail by the reason unrelated to this test. If the test is successful, the generated events are cleaned up. And if not, we cannot guarantee that the kprobe events will work

[PATCH v3 2/3] tracing/kprobe: Integrate test warnings into WARN_ONCE

2024-06-11 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Cleanup the redundant WARN_ON_ONCE(cond) + pr_warn(msg) into WARN_ONCE(cond, msg). Also add some WARN_ONCE() for hitcount check. These WARN_ONCE() errors makes it easy to handle errors from ktest. Suggested-by: Steven Rostedt Signed-off-by: Masami Hiramatsu

[PATCH v3 1/3] tracing: Build event generation tests only as modules

2024-06-11 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) The kprobes and synth event generation test modules add events and lock (get a reference) those event file reference in module init function, and unlock and delete it in module exit function. This is because those are designed for playing as modules. If we make

[PATCH v3 0/3] tracing: Fix some selftest issues

2024-06-11 Thread Masami Hiramatsu (Google)
() and pr_warn() instead of removing WARN_ONCE() because this warning messages are needed to ktest to handle errors. Thank you, --- Masami Hiramatsu (Google) (3): tracing: Build event generation tests only as modules tracing/kprobe: Integrate test warnings into WARN_ONCE tracing

Re: [PATCH 2/3] tracing/kprobe: Remove unneeded WARN_ON_ONCE() in selftests

2024-06-10 Thread Google
On Mon, 10 Jun 2024 20:18:13 -0400 Steven Rostedt wrote: > On Tue, 11 Jun 2024 06:26:44 +0900 > "Masami Hiramatsu (Google)" wrote: > > > From: Masami Hiramatsu (Google) > > > > Since the kprobe-events selftest shows OK or NG with the reason, the &

Re: [PATCH 2/3] tracing/kprobe: Remove unneeded WARN_ON_ONCE() in selftests

2024-06-10 Thread Google
On Mon, 10 Jun 2024 17:40:52 -0400 Steven Rostedt wrote: > On Tue, 11 Jun 2024 06:26:44 +0900 > "Masami Hiramatsu (Google)" wrote: > > > From: Masami Hiramatsu (Google) > > > > Since the kprobe-events selftest shows OK or NG with the reason, the &

Re: [PATCHv7 bpf-next 2/9] uprobe: Wire up uretprobe system call

2024-06-10 Thread Google
for native > 64-bit process. > BTW, this does not cleanly applied to probes/for-next, based on 6.10-rc1. Which version did you use? Thank you, > Reviewed-by: Oleg Nesterov > Reviewed-by: Masami Hiramatsu (Google) > Acked-by: Andrii Nakryiko > Signed-off-by: Jiri Olsa

Re: [PATCHv7 bpf-next 8/9] selftests/bpf: Add uretprobe shadow stack test

2024-06-10 Thread Google
On Thu, 23 May 2024 14:11:48 +0200 Jiri Olsa wrote: > Adding uretprobe shadow stack test that runs all existing > uretprobe tests with shadow stack enabled if it's available. > According to the document and sample code, this looks good to me. Reviewed-by: Masami Hiramatsu (Go

Re: [PATCHv7 bpf-next 0/9] uprobe: uretprobe speed up

2024-06-10 Thread Google
; > kernel/events/uprobes.c | 24 -- > > > kernel/sys_ni.c | 2 + > > > tools/include/linux/compiler.h | 4 + > > > tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c | 123 > > > - > > > tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c | 385 > > > +++ > > > tools/testing/selftests/bpf/progs/uprobe_syscall.c | 15 > > > tools/testing/selftests/bpf/progs/uprobe_syscall_executed.c | 17 > > > tools/testing/selftests/x86/test_shadow_stack.c | 145 > > > ++ > > > 15 files changed, 860 insertions(+), 10 deletions(-) > > > create mode 100644 > > > tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c > > > create mode 100644 tools/testing/selftests/bpf/progs/uprobe_syscall.c > > > create mode 100644 > > > tools/testing/selftests/bpf/progs/uprobe_syscall_executed.c > > > > > > Jiri Olsa (1): > > > man2: Add uretprobe syscall page > > > > > > man/man2/uretprobe.2 | 56 > > > > > > 1 file changed, 56 insertions(+) > > > create mode 100644 man/man2/uretprobe.2 -- Masami Hiramatsu (Google)

[PATCH 3/3] tracing/kprobe: Remove cleanup code unrelated to selftest

2024-06-10 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) This cleanup all kprobe events code is not related to the selftest itself, and it can fail by the reason unrelated to this test. If the test is successful, the generated events are cleaned up. And if not, we cannot guarantee that the kprobe events will work

[PATCH 2/3] tracing/kprobe: Remove unneeded WARN_ON_ONCE() in selftests

2024-06-10 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Since the kprobe-events selftest shows OK or NG with the reason, the WARN_ON_ONCE()s for each place are redundant. Let's remove it. Signed-off-by: Masami Hiramatsu (Google) --- kernel/trace/trace_kprobe.c | 26 +- 1 file change

[PATCH 1/3] tracing: Build event generation tests only as modules

2024-06-10 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) The kprobes and synth event generation test modules add events and lock (get a reference) those event file reference in module init function, and unlock and delete it in module exit function. This is because those are designed for playing as modules. If we make

[PATCH 0/3] tracing: Fix some selftest issues

2024-06-10 Thread Masami Hiramatsu (Google)
(because there are warning messages already) and the cleanup code is redundant. This series fixes those issues. Thank you, --- Masami Hiramatsu (Google) (3): tracing: Build event generation tests only as modules tracing/kprobe: Remove unneeded WARN_ON_ONCE() in selftests tracing

Re: [PATCH 0/3] tracing: Fix some selftest issues

2024-06-09 Thread Google
On Fri, 31 May 2024 03:24:25 -0400 Steven Rostedt wrote: > On Fri, 31 May 2024 11:37:21 +0900 > Masami Hiramatsu (Google) wrote: > > > So, in summary, it is designed to be a module. Steve, I think these tests > > should be kept as modules. There are many reason to do so.

Re: [PATCH] function_graph: Rename BYTE_NUMBER to CHAR_NUMBER in selftests

2024-06-08 Thread Google
On Thu, 6 Jun 2024 08:18:46 -0400 Steven Rostedt wrote: > From: "Steven Rostedt (Google)" > > The function_graph selftests checks various size variables to pass from > the entry of the function to the exit. It tests 1, 2, 4 and 8 byte words. > The 1 byte macro was ca

Re: [PATCH v2 0/5] ftrace: Clean up and comment code

2024-06-05 Thread Google
on names were not descriptive enough, or at least, they needed > comments. > > This series moves to solve some of that via changing a couple function > names and parameters and adding comments to many of them. > This series looks good to me. Acked-by: Masami Hiramatsu (Google) for

Re: [PATCH v2 1/5] ftrace: Rename dup_hash() and comment it

2024-06-05 Thread Google
On Wed, 05 Jun 2024 14:03:35 -0400 Steven Rostedt wrote: > From: "Steven Rostedt (Google)" > > The name "dup_hash()" is a misnomer as it does not duplicate the hash that > is passed in, but instead moves its entities from that hash to a newly > alloc

Re: [PATCH 0/6] ftrace: Minor fixes for sparse and kernel test robot

2024-06-05 Thread Google
ngs. > > But the reports from kernel test robot need to be fixed. All looks good to me. Acked-by: Masami Hiramatsu (Google) Thank you! > > Steven Rostedt (Google) (6): > ftrace: Declare function_trace_op in header to quiet sparse warning > ftrace: Assign ftra

Re: [PATCH 3/5] ftrace: Remove "filter_hash" parameter from ftrace_hash_rec_disable/enable()

2024-06-05 Thread Google
On Tue, 04 Jun 2024 17:28:20 -0400 Steven Rostedt wrote: > From: "Steven Rostedt (Google)" > > The functions ftrace_hash_rec_disable() and ftrace_hash_rec_enable() > always has 1 passed to its "ftrace_hash" parameter. Remove the parameter > and pass

Re: [PATCH 1/5] ftrace: Rename dup_hash() and comment it

2024-06-05 Thread Google
On Tue, 04 Jun 2024 17:28:18 -0400 Steven Rostedt wrote: > From: "Steven Rostedt (Google)" > > The name "dup_hash()" is a misnomer as it does not duplicate the hash that > is passed in, but instead moves its entities from that hash to a newly > alloc

Re: [PATCH v3 00/27] function_graph: Allow multiple users for function graph tracing

2024-06-04 Thread Google
On Tue, 4 Jun 2024 08:18:50 -0400 Steven Rostedt wrote: > > Masami, > > This series passed all my tests, are you comfortable with me pushing > them to linux-next? Yes, this series looks good to me too. Reviewed-by: Masami Hiramatsu (Google) for the series. Thank you!

Re: [PATCH 0/3] tracing: Fix some selftest issues

2024-06-04 Thread Google
On Tue, 4 Jun 2024 09:57:46 -0400 Steven Rostedt wrote: > On Fri, 31 May 2024 23:20:47 +0900 > Masami Hiramatsu (Google) wrote: > > > The major conflict happens when the boot-time test cleans up the kprobe > > events by > > > > dyn_events_release_all(&

Re: [PATCH v2 2/3] tracing/fprobe: Support raw tracepoint events on modules

2024-06-03 Thread Google
On Mon, 3 Jun 2024 15:50:55 -0400 Mathieu Desnoyers wrote: > On 2024-06-01 04:22, Masami Hiramatsu (Google) wrote: > > From: Masami Hiramatsu (Google) > > > > Support raw tracepoint event on module by fprobe events. > > Since it only uses for_each_kernel_tracep

Re: [PATCH v2 11/27] ftrace: Allow subops filtering to be modified

2024-06-03 Thread Google
On Mon, 3 Jun 2024 10:52:50 -0400 Steven Rostedt wrote: > On Mon, 3 Jun 2024 11:37:23 +0900 > Masami Hiramatsu (Google) wrote: > > > On Sat, 01 Jun 2024 23:37:55 -0400 > > Steven Rostedt wrote: > > > > [...] > > > > > > +static int f

Re: [PATCH v2 24/27] function_graph: Use static_call and branch to optimize entry function

2024-06-03 Thread Google
ementation is enough. Thank you, > > -- Steve -- Masami Hiramatsu (Google)

Re: [PATCH] lib: test_objpool: add missing MODULE_DESCRIPTION() macro

2024-06-02 Thread Google
8d937f8666 > > > > Looks good to me. Thanks for the update. > > I added Masami Hiramatsu and linux-trace in the loop. > > Reviewed-by: Matt Wu Thanks, let me pick this to probes/for-next branch. Thank you, > > Regards, > Matt Wu > -- Masami Hiramatsu (Google)

Re: [PATCH v2 24/27] function_graph: Use static_call and branch to optimize entry function

2024-06-02 Thread Google
On Sat, 01 Jun 2024 23:38:08 -0400 Steven Rostedt wrote: > From: "Steven Rostedt (Google)" > > In most cases function graph is used by a single user. Instead of calling > a loop to call function graph callbacks in this case, call the function > entry callback direct

Re: [PATCH v2 10/27] ftrace: Add subops logic to allow one ops to manage many

2024-06-02 Thread Google
re. I guess I was thinking too much of strcmp() logic :-p Yeah, it's the curse of the C programmer :( (even it is good for sorting.) Thank you, > > > > > Thank you, > > Thanks for the review. > > -- Steve > > > > > > +{ > > > + struct ftrace_func_entry *entry; > > > + int size; > > > + int i; > > > + > > > + if (!A || A == EMPTY_HASH) > > > + return !(!B || B == EMPTY_HASH); > > > + > > > + if (!B || B == EMPTY_HASH) > > > + return !(!A || A == EMPTY_HASH); > > > + > > > + if (A->count != B->count) > > > + return 1; > > > + > > > + size = 1 << A->size_bits; > > > + for (i = 0; i < size; i++) { > > > + hlist_for_each_entry(entry, &A->buckets[i], hlist) { > > > + if (!__ftrace_lookup_ip(B, entry->ip)) > > > + return 1; > > > + } > > > + } > > > + > > > + return 0; > > > +} > > > + > > > > > -- Masami Hiramatsu (Google)

Re: [PATCH v2 11/27] ftrace: Allow subops filtering to be modified

2024-06-02 Thread Google
&op->subop_list, list) { > + if ((subops->flags & FTRACE_OPS_FL_ENABLED) && > + subops->func_hash == ops->func_hash) { > + return > ftrace_hash_move_and_update_subops(subops, orig_hash, hash, enable); > + } > + } > + } while_for_each_ftrace_op(op); > + } > + > old_hash = *orig_hash; > old_hash_ops.filter_hash = ops->func_hash->filter_hash; > old_hash_ops.notrace_hash = ops->func_hash->notrace_hash; > -- > 2.43.0 > > -- Masami Hiramatsu (Google)

Re: [PATCH v2 10/27] ftrace: Add subops logic to allow one ops to manage many

2024-06-02 Thread Google
+} > + > +/* Returns 0 on equal or non-zero on non-equal */ > +static int compare_ops(struct ftrace_hash *A, struct ftrace_hash *B) nit: Isn't it better to be `bool hash_equal()` and return true if A == B ? Thank you, > +{ > + struct ftrace_func_entry *entry; > + int size; > + int i; > + > + if (!A || A == EMPTY_HASH) > + return !(!B || B == EMPTY_HASH); > + > + if (!B || B == EMPTY_HASH) > + return !(!A || A == EMPTY_HASH); > + > + if (A->count != B->count) > + return 1; > + > + size = 1 << A->size_bits; > + for (i = 0; i < size; i++) { > + hlist_for_each_entry(entry, &A->buckets[i], hlist) { > + if (!__ftrace_lookup_ip(B, entry->ip)) > + return 1; > + } > + } > + > + return 0; > +} > + -- Masami Hiramatsu (Google)

Re: [PATCH RFC 2/4] error-injection: support static keys around injectable functions

2024-06-02 Thread Google
long addr); > +int get_injectable_error_type(unsigned long addr, struct static_key > **key_addr); This seems like an add-hoc change. Since this is called in a cold path (only used when adding new function), can you add new `struct static_key *get_injection_key(unsigned long addr)` to find the static_key from the address? Other part looks good to me. Thank you, -- Masami Hiramatsu (Google)

Re: [syzbot] Monthly trace report (May 2024)

2024-06-01 Thread Google
oglegroups.com. > > To disable reminders for individual bugs, reply with the following command: > #syz set no-reminders > > To change bug's subsystems, reply with: > #syz set subsystems: new-subsystem > > You may send multiple commands in a single email message. -- Masami Hiramatsu (Google)

Re: [PATCH] KUnit: add missing MODULE_DESCRIPTION() macros for lib/test_*.ko

2024-06-01 Thread Google
ity test for *probes"); nit: Could you make it "simple sanity test for k*probes" ? because there is test_fprobe.c. Thank you, -- Masami Hiramatsu (Google)

Re: [PATCH 10/20] function_graph: Have the instances use their own ftrace_ops for filtering

2024-06-01 Thread Google
On Fri, 31 May 2024 18:49:10 -0400 Steven Rostedt wrote: > On Fri, 31 May 2024 23:50:23 +0900 > Masami Hiramatsu (Google) wrote: > > > So is it similar to the fprobe/kprobe, use shared signle ftrace_ops, > > but keep each fgraph has own hash table? > > Sort of. >

Re: [PATCH] samples: kprobes: add missing MODULE_DESCRIPTION() macros

2024-06-01 Thread Google
) > +MODULE_DESCRIPTION("sample kernel module showing the use of return probes"); > MODULE_LICENSE("GPL"); > > --- > base-commit: b050496579632f86ee1ef7e7501906db579f3457 > change-id: 20240601-md-samples-kprobes-efb32cbcc8dd > -- Masami Hiramatsu (Google)

[PATCH v2 3/3] sefltests/tracing: Add a test for tracepoint events on modules

2024-06-01 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Add a test case for tracepoint events on modules. This checks if it can add and remove the events correctly. Signed-off-by: Masami Hiramatsu (Google) --- tools/testing/selftests/ftrace/config |1 + .../test.d/dynevent

[PATCH v2 2/3] tracing/fprobe: Support raw tracepoint events on modules

2024-06-01 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Support raw tracepoint event on module by fprobe events. Since it only uses for_each_kernel_tracepoint() to find a tracepoint, the tracepoints on modules are not handled. Thus if user specified a tracepoint on a module, it shows an error. This adds new

[PATCH v2 1/3] tracepoint: Support iterating over tracepoints on modules

2024-06-01 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Add for_each_module_tracepoint() for iterating over tracepoints on modules. This is similar to the for_each_kernel_tracepoint() but only for the tracepoints on modules (not including kernel built-in tracepoints). Signed-off-by: Masami Hiramatsu (Google

[PATCH v2 0/3] tracing/probes: Support tracepoint events on modules

2024-06-01 Thread Masami Hiramatsu (Google)
Hi, This series implements the tracepoint events on modules. This version separates a patch for tracepoint subsystem from fprobe-event patch, and adds a selftests for tracepoint events on modules. Thank you, --- Masami Hiramatsu (Google) (3): tracepoint: Support iterating over

Re: [PATCH] tracing/fprobe: Support raw tracepoint events on modules

2024-05-31 Thread Google
.com/intel-lab-lkp/linux/commits/Masami-Hiramatsu-Google/tracing-fprobe-Support-raw-tracepoint-events-on-modules/20240531-175013 > base: linus/master > patch link: > https://lore.kernel.org/r/171714888633.198965.13093663631481169611.stgit%40devnote2 > patch subject: [PATCH] tracing

Re: [PATCH 10/20] function_graph: Have the instances use their own ftrace_ops for filtering

2024-05-31 Thread Google
On Fri, 31 May 2024 02:03:46 -0400 Steven Rostedt wrote: > On Fri, 31 May 2024 12:12:41 +0900 > Masami Hiramatsu (Google) wrote: > > > On Thu, 30 May 2024 22:30:57 -0400 > > Steven Rostedt wrote: > > > > > On Fri, 24 May 2024 22:37:02 -0400 > > >

Re: [PATCH 0/3] tracing: Fix some selftest issues

2024-05-31 Thread Google
On Fri, 31 May 2024 03:24:25 -0400 Steven Rostedt wrote: > On Fri, 31 May 2024 11:37:21 +0900 > Masami Hiramatsu (Google) wrote: > > > So, in summary, it is designed to be a module. Steve, I think these tests > > should be kept as modules. There are many reason to do so.

[PATCH] tracing/fprobe: Support raw tracepoint events on modules

2024-05-31 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Support raw tracepoint event on module by fprobe events. Since it only uses for_each_kernel_tracepoint() to find a tracepoint, the tracepoints on modules are not handled. Thus if user specified a tracepoint on a module, it shows an error. This adds new

Re: [PATCH 10/20] function_graph: Have the instances use their own ftrace_ops for filtering

2024-05-30 Thread Google
> it avoid pushing on shadow stack multiple times on the same function. > > So I found a major design flaw in this patch. > > > > > Co-developed with Masami Hiramatsu: > > Link: > > https://lore.kernel.org/linux-trace-kernel/171509102088.162236.15758883237657317789.s

Re: [PATCH 0/3] tracing: Fix some selftest issues

2024-05-30 Thread Google
On Wed, 29 May 2024 11:01:43 -0500 Tom Zanussi wrote: > Hi Masami, > > On Wed, 2024-05-29 at 08:38 +0900, Masami Hiramatsu wrote: > > On Wed, 29 May 2024 01:46:40 +0900 > > Masami Hiramatsu (Google) wrote: > > > > > On Mon, 27 May 2024 19:29:

Re: [PATCH 0/3] tracing: Fix some selftest issues

2024-05-28 Thread Google
On Wed, 29 May 2024 01:46:40 +0900 Masami Hiramatsu (Google) wrote: > On Mon, 27 May 2024 19:29:07 -0400 > Steven Rostedt wrote: > > > On Sun, 26 May 2024 19:10:57 +0900 > > "Masami Hiramatsu (Google)" wrote: > > > > > Hi, > > > > &g

Re: [PATCH 0/3] tracing: Fix some selftest issues

2024-05-28 Thread Google
On Mon, 27 May 2024 19:29:07 -0400 Steven Rostedt wrote: > On Sun, 26 May 2024 19:10:57 +0900 > "Masami Hiramatsu (Google)" wrote: > > > Hi, > > > > Here is a series of some fixes/improvements for the test modules and boot > > time selftest of kp

Re: [PATCH v2 2/2] selftests/user_events: Add non-spacing separator check

2024-05-27 Thread Google
ch > and not return -EADDRINUSE. > > Add a non-spacing separator case to our self-test register case to ensure > it works going forward. > Looks good to me. Acked-by: Masami Hiramatsu (Google) Thanks! > Signed-off-by: Beau Belgrave > --- > tools/testing/selftests/user_

Re: [PATCH v2] tracing/probes: fix error check in parse_btf_field()

2024-05-27 Thread Google
trace_probe_log_err(ctx->offset, NO_BTF_FIELD); > return -ENOENT; > -- > 2.35.3 > -- Masami Hiramatsu (Google)

Re: [PATCH 00/20] function_graph: Allow multiple users for function graph tracing

2024-05-26 Thread Google
for update the patches! I think your changes are good. I just have some comments and replied. So, the plan is to push this series in the tracing/for-next? I will port my fprobe part on it and run some tests. Thank you, > > Based on Linus commit: 0eb03c7e8e2a4cc3653eb5eeb2d2001182071215 >

Re: [PATCH 04/20] function_graph: Allow multiple users to attach to function graph

2024-05-26 Thread Google
;t be too hard to manage. > > Co-developed with Masami Hiramatsu: > Link: > https://lore.kernel.org/linux-trace-kernel/171509096221.162236.8806372072523195752.stgit@devnote2 > Thanks for update this. I have some comments below. > Signed-off-by: Steven Rostedt (VMware) > Signed-

Re: [PATCH 20/20] function_graph: Use bitmask to loop on fgraph entry

2024-05-26 Thread Google
On Fri, 24 May 2024 22:37:12 -0400 Steven Rostedt wrote: > From: "Steven Rostedt (Google)" > > Instead of looping through all the elements of fgraph_array[] to see if > there's an gops attached to one and then calling its gops->func(). Create > a fgraph_arr

Re: [PATCH 19/20] function_graph: Use for_each_set_bit() in __ftrace_return_to_handler()

2024-05-26 Thread Google
On Fri, 24 May 2024 22:37:11 -0400 Steven Rostedt wrote: > From: "Steven Rostedt (Google)" > > Instead of iterating through the entire fgraph_array[] and seeing if one > of the bitmap bits are set to know to call the array's retfunc() function, > use for_each_

Re: [PATCH 19/20] function_graph: Use for_each_set_bit() in __ftrace_return_to_handler()

2024-05-26 Thread Google
On Fri, 24 May 2024 22:37:11 -0400 Steven Rostedt wrote: > From: "Steven Rostedt (Google)" > > Instead of iterating through the entire fgraph_array[] and seeing if one > of the bitmap bits are set to know to call the array's retfunc() function, > use for_each_

Re: [PATCH] ftrace: Fix stack trace entry generated by ftrace_pid_func()

2024-05-26 Thread Google
if (!(ops->flags & FTRACE_OPS_FL_PID) || !ops->private) >107return false; >108 >109tr = ops->private; >110 >111return tr->function_pids != NULL || > tr->function_no_pids != NULL; >112} >113 > > -- > 0-DAY CI Kernel Test Service > https://github.com/intel/lkp-tests/wiki -- Masami Hiramatsu (Google)

Re: [PATCH] tracing/probes: fix error check in parse_btf_field()

2024-05-26 Thread Google
On Sun, 26 May 2024 14:27:56 +0200 Carlos López wrote: > > Hi, > > On 26/5/24 12:17, Masami Hiramatsu (Google) wrote: > > On Sat, 25 May 2024 20:21:32 +0200 > > Carlos López wrote: > > > >> btf_find_struct_member() might return NULL or an error via

Re: [PATCH] tracing/probes: fix error check in parse_btf_field()

2024-05-26 Thread Google
_BTF_FIELD); > return -ENOENT; > -- > 2.35.3 > -- Masami Hiramatsu (Google)

[PATCH 3/3] tracing/kprobe: Remove cleanup code unrelated to selftest

2024-05-26 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) This cleanup all kprobe events code is not related to the selftest itself, and it can fail by the reason unrelated to this test. If the test is successful, the generated events are cleaned up. And if not, we cannot guarantee that the kprobe events will work

[PATCH 2/3] tracing/kprobe: Remove unneeded WARN_ON_ONCE() in selftests

2024-05-26 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Since the kprobe-events selftest shows OK or NG with the reason, the WARN_ON_ONCE()s for each place are redundant. Let's remove it. Signed-off-by: Masami Hiramatsu (Google) --- kernel/trace/trace_kprobe.c | 26 +- 1 file change

[PATCH 1/3] tracing: Build event generation tests only as modules

2024-05-26 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Since the kprobes and synth event generation tests adds and enable generated events in init_module() and delete it in exit_module(), if we make it as built-in, those events are left in kernel and cause kprobe event self-test failure. [ 97.349708

[PATCH 0/3] tracing: Fix some selftest issues

2024-05-26 Thread Masami Hiramatsu (Google)
main problem is that the test module should not be built-in. But I also think this WARNING message is useless (because there are warning messages already) and the cleanup code is redundant. This series fixes those issues. Thank you, --- Masami Hiramatsu (Google) (3): tracing: Build event

Re: [PATCH v10 00/36] tracing: fprobe: function_graph: Multi-function graph and fprobe on fgraph

2024-05-25 Thread Google
On Fri, 24 May 2024 18:41:56 -0400 Steven Rostedt wrote: > On Tue, 7 May 2024 23:08:00 +0900 > "Masami Hiramatsu (Google)" wrote: > > > Steven Rostedt (VMware) (15): > > function_graph: Convert ret_stack to a series of longs > > fgraph: Us

<    1   2   3   4   5   6   7   8   9   10   >