's ref
> count.
>
Looks good to me.
Reviewed-by: Masami Hiramatsu (Google)
Thank you,
> Fixes: e645535a954ad ("tracing: Add option to use memmapped memory for trace
> boot instance")
> Signed-off-by: Steven Rostedt (Google)
> ---
> kernel/trace/
d below and use it around.
#define EVENT_NAME_BUFSIZE (MAX_EVENT_NAME_LEN + 1)
Anyway, I think this fix is correct.
Acked-by: Masami Hiramatsu (Google)
Thank you,
> Fixes: dec65d79fd26 ("tracing/probe: Check event name length correctly")
> Signed-off-by: Leo Yan
> ---
>
&g
From: Masami Hiramatsu (Google)
Simplify return address printing in the function graph tracer by removing
fgraph_extras. Since this feature is only used by the function graph
tracer and the feature flags can directly accessible from the function
graph tracer, fgraph_extras can be removed from
trace_seq_putc(s, '\n');
And this is not needed. So for example,
trace_seq_puts(s, "[FTRACE TRAMPOLINE]\n");
is enough.
> + continue;
> + }
> seq_print_ip_sym(s, (*p) + delta, flags);
> trace_seq_putc(s, '\n');
> }
Thank you,
> --
> 2.46.2
>
--
Masami Hiramatsu (Google)
On Thu, 10 Oct 2024 10:40:02 +0800
Donglin Peng wrote:
> On Thu, Oct 10, 2024 at 7:35 AM Masami Hiramatsu (Google)
> wrote:
> >
> > From: Masami Hiramatsu (Google)
> >
> > Simplify return address printing in the function graph tracer by removing
> > fgrap
From: Masami Hiramatsu (Google)
Simplify return address printing in the function graph tracer by removing
fgraph_extras. Since this feature is only used by the function graph
tracer and the feature flags can directly accessible from the function
graph tracer, fgraph_extras can be removed from
On Wed, 9 Oct 2024 13:19:20 -0400
Steven Rostedt wrote:
>
> Hi Masami,
>
> Care to send this as a real patch?
Yes, let me send it.
Thanks,
--
Masami Hiramatsu (Google)
tras" to the fgraph callback interface
but it is only used in function_graph tracer. Can we move this in the
function_graph tracer, like below?
Thank you,
>From 8c2851452dd11a3a20ab22bd6bf8dd663c3c4b9c Mon Sep 17 00:00:00 2001
From: "Masami Hiramatsu (Google)"
Date: Thu, 10 Oct 2024 00:
is looks good to me.
Acked-by: Masami Hiramatsu (Google)
For x86 and generic part.
Thank you,
> Acked-by: Catalin Marinas
> Signed-off-by: Steven Rostedt (Google)
> ---
> Changes since v1:
> https://lore.kernel.org/20241007204743.41314...@gandalf.local.home
>
> - Moved
ll also make it easier to add new accessor functions to
> ftrace_regs as it will mean having to touch less architectures.
>
> Suggested-by: Masami Hiramatsu (Google)
> Signed-off-by: Steven Rostedt (Google)
> ---
> arch/arm64/include/asm/ftrace.h | 1 +
> arch/loongarch/
s no #endif for CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS.
I wonder how it passed the build. (#ifdef block does not affect over
the file boundary?
Thank you,
--
Masami Hiramatsu (Google)
gt;
Looks good to me.
Acked-by: Masami Hiramatsu (Google)
Thanks!
> Signed-off-by: Steven Rostedt (Google)
> ---
> Changes since v1:
> https://lore.kernel.org/20240821150903.05c6c...@gandalf.local.home
>
> - Added comment to why we are doing a sleep 1
>
> - Now that the f
> set_events ${INSTANCE_FOO}
> echo 1 > ${INSTANCE_FOO}/options/sym-offset
> echo 'tcp_orphan*' > ${INSTANCE_FOO}/set_ftrace_notrace
> echo function > ${INSTANCE_FOO}/current_tracer
>
> echo 1 > ${TRACE_PATH}/tracing_on
> echo 1 > ${INSTAN
ck()
> + * function_stack_trace_call()
> + * ftrace_call()
> */
> #define STACK_SKIP 3
> -#endif
>
> static void
> function_stack_trace_call(unsigned long ip, unsigned long parent_ip,
> --
> 2.46.2
>
--
Masami Hiramatsu (Google)
On Tue, 1 Oct 2024 19:32:34 -0400
Steven Rostedt wrote:
> On Wed, 2 Oct 2024 08:10:37 +0900
> Masami Hiramatsu (Google) wrote:
> > >
> > > I may add some compiler hacks to enforce this. Something like:
> > >
> > > struct ftrac
redundant, but I think it would be more
> maintainable to treat
>
> "skip(and skipped functions)" separately only at the top(parent) of
> functions that display stack trace.
I think you'd better make a set of test programs which gets the stacktrace
with several different conditions (combinations of tracers/probes/kconfgis)
at first. Then we can make sure it does not break anything.
Thank you,
--
Masami Hiramatsu (Google)
a = (unsigned long *)fgraph_retrieve_data(gops->idx, &size);
+ if (WARN_ON_ONCE(!fgraph_data))
return;
+ size_words = SIZE_IN_LONG(size);
+ ret_ip = ftrace_regs_get_instruction_pointer(fregs);
+
Thank you,
>
> -- Steve
--
Masami Hiramatsu (Google)
On Tue, 17 Sep 2024 11:14:54 +0100
Will Deacon wrote:
> On Sun, Sep 15, 2024 at 05:22:04AM -0400, Steven Rostedt wrote:
> > On Fri, 13 Sep 2024 00:09:35 +0900
> > "Masami Hiramatsu (Google)" wrote:
> >
> > > From: Masami Hiramatsu (Google)
> > >
ilable on s390
> anymore with the full series, since HAVE_FTRACE_GRAPH_FUNC is not
> available.
Right, this is required for implementing fprobe.
>
> Also the s390 variant of arch_ftrace_fill_perf_regs() seems to be
> incorrect.
Can you tell me what part will be wrong?
Thank you,
>
> Looks like some work is needed from our side.
--
Masami Hiramatsu (Google)
ps://lore.kernel.org/linux-trace-kernel/172639136989.366111.11359590127009702129.stgit@devnote2/
>
> >
> > > On Fri, 13 Sep 2024 00:08:40 +0900
> > > "Masami Hiramatsu (Google)" wrote:
> > >
> > > > From: Masami Hiramatsu (Google)
&g
On Mon, 30 Sep 2024 11:32:31 -0400
Steven Rostedt wrote:
> On Tue, 1 Oct 2024 00:28:13 +0900
> Masami Hiramatsu (Google) wrote:
>
> > On Mon, 30 Sep 2024 10:06:30 -0400
> > Steven Rostedt wrote:
> >
> > > On Mon, 30 Sep 2024 09:33:42 +0800
> > &g
n >128 arguments, but we still attempt to
> process the excess unparsed ones.
OK, can you update your version to return an error from each probe?
Thank you,
--
Masami Hiramatsu (Google)
egister/unregister APIs are exposed to the kernel modules,
since systemtap had been introduced this feature.
Thank you,
>
> If uprobes can be used without uprobe events, like kprobes can be used
> without kprobe events, then I can see having uprobes as a separate config
> menu option. If not, then no, it shouldn't be.
>
> -- Steve
--
Masami Hiramatsu (Google)
[001] ...1.18.352604:
=> ftrace_regs_call
=> vfs_write
=> ksys_write
=> do_syscall_64
=> entry_SYSCALL_64_after_hwframe
--
As you can see, myevent skips "vfs_write".
(and function tracer still have ftrace_regs_call() )
Thank you,
>
> preempt_disable_notrace();
>
> --
> 2.46.1
>
--
Masami Hiramatsu (Google)
if (argc > MAX_TRACE_ARGS + 2)
+ return -E2BIG;
+
if (argc)
ret = createfn(argc, (const char **)argv);
--
Masami Hiramatsu (Google)
depends on PERF_EVENTS
> - select UPROBES
> select PROBE_EVENTS
> select DYNAMIC_EVENTS
> select TRACING
>
> Thanks,
> Tiezhu
>
>
--
Masami Hiramatsu (Google)
On Wed, 18 Sep 2024 23:22:41 +0200
Andrii Nakryiko wrote:
> On Sun, Sep 15, 2024 at 11:09 AM Masami Hiramatsu (Google)
> wrote:
> >
> > Hi,
> >
> > Here is the 15th version of the series to re-implement the fprobe on
> > function-graph tracer. Th
On Fri, 13 Sep 2024 08:03:51 +0200
Sven Schnelle wrote:
> Sven Schnelle writes:
>
> > Masami Hiramatsu (Google) writes:
> >
> >> On Fri, 6 Sep 2024 10:07:38 -0400
> >> Steven Rostedt wrote:
> >>
> >>> On Fri, 06 Sep 2024 08:18:02 +0
On Mon, 16 Sep 2024 22:15:57 +
Sami Tolvanen wrote:
> uses struct pt_regs in several places. Include
> to ensure it's visible. This is needed to make sure
> object files that only include compile.
Looks good to me.
Acked-by: Masami Hiramatsu (Google)
Thanks!
>
gt; include/trace/perf.h| 43 ++--
> include/trace/trace_events.h| 61 +--
> init/Kconfig| 1 +
> kernel/entry/common.c | 4 +-
> kernel/trace/trace_syscalls.c | 36 --
> 9 files changed, 218 insertions(+), 36 deletions(-)
>
> --
> 2.39.2
--
Masami Hiramatsu (Google)
s to respect the current expectations within ftrace ring buffer
> code.
>
> This change does not yet allow ftrace to take page faults per se within
> its probe, but allows its existing probes to adapt to the upcoming
> change.
OK, this looks good to me.
Acked-by: Masami Hir
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
From: Masami Hiramatsu (Google)
Add get_entry_ip() implementation for arm64. This is based on the
information in ftrace_call_adjust() on arm64. Basically function entry
address = ftrace call entry_ip - 4, but when there is a BTI at the first
instruction, we need one more instruction back
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
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
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
From: Masami Hiramatsu (Google)
Since the new fgraph requires to initialize fgraph_ops.ops.func_hash before
calling register_ftrace_graph(), initialize it with default (tracing all
functions) parameter.
Signed-off-by: Masami Hiramatsu (Google)
---
kernel/trace/ftrace.c |4
1 file
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
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
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
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
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
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-
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
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
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
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
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
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
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
llback runs. Thus
the address validation must be done before using it in the return
callback.
Download
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/lin
tead, have the only two users of it (function graph tracer and the
> profiler) store it in its own shadow stack variable.
This series looks good to me. Instead of adding add-hoc flag, this
solves call-time clearer.
For this series,
Acked-by: Masami Hiramatsu (Google)
Thank you,
>
> St
on uretprobes side.
>
> Even single-thread (no contention) performance is slightly better: 3.276
> mln/s to 3.396 mln/s (+3.5%) for uprobes, and 2.055 mln/s to 2.174 mln/s
> (+5.8%) for uretprobes.
>
> We also select TASKS_TRACE_RCU for UPROBES in Kconfig due to the new
> depe
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
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
From: Masami Hiramatsu (Google)
Since the new fgraph requires to initialize fgraph_ops.ops.func_hash before
calling register_ftrace_graph(), initialize it with default (tracing all
functions) parameter.
Signed-off-by: Masami Hiramatsu (Google)
---
kernel/trace/ftrace.c |4
1 file
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
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
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
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
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
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-
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
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
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
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
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
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
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
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
ll valid. Note that it is
possible to unregister fprobe before the return callback runs. Thus
the address validation must be done before using it in the return
callback.
Download
This series can be applied against the ftrace/for-next branch in
linux-trace tree.
This series can also be
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
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
On Wed, 11 Sep 2024 20:27:27 +0200
Jiri Olsa wrote:
> On Sun, Aug 18, 2024 at 09:47:53PM +0900, Masami Hiramatsu (Google) wrote:
> > Hi,
> >
> > Here is the 13th version of the series to re-implement the fprobe on
> > function-graph tracer. The previous
c.
It does not regress kretprobe, but introduces the same problem to
fprobe. And since fprobe-on-fgraph was boosted by this problem,
I think that is not a separate topic.
Thank you,
--
Masami Hiramatsu (Google)
On Wed, 11 Sep 2024 09:24:34 +0900
Masami Hiramatsu (Google) wrote:
> Let me gently ping :)
>
> Let me check it should be rebased on tracing/for-next again. But basically
> this should be the same...
I found a build error on riscv. Let me fix that.
Thanks,
>
> On Sun, 18
inux-trace-kernel/172398527264.293426.2050093948411376857.stgit@devnote2/
> > > [1]
> > > https://lore.kernel.org/bpf/164338038439.242.17564843625400931820.stgit@devnote2/
> > >
> > > >
> > > > Again, just letting you know.
> > > >
> > > > -- Steve
> >
> >
> > --
> > Masami Hiramatsu (Google)
--
Masami Hiramatsu (Google)
d the current pt_regs to ftrace_regs
series is separated series. But it was broken. So I tried to find the
correct way to fix it, and finally introduced the current fprobe on
fgraph series. performance improvement is just a side effect.
Thank you,
>
>
> [0]
> https://lore.kernel.org/bpf/164338038439.242.17564843625400931820.stgit@devnote2/
>
> > pt_regs. So we need to use ftrace_regs for that.
> > So eventually, we need my fprobe series.
> >
> > https://lore.kernel.org/bpf/164338038439.242.17564843625400931820.stgit@devnote2/
> >
> > Thank you,
> >
> > >
> > > Note that there was already an implementation (see [1]), but for some
> > > reason it never made it.
> > >
> > > [1]
> > > https://lore.kernel.org/bpf/164338038439.242.17564843625400931820.stgit@devnote2/
> > > [2]
> > > https://lore.kernel.org/bpf/172562357215.467568.2172858907419105155.b4...@ellerman.id.au/
> > >
> > > >
> > > > -- Andrii
> >
> >
> > --
> > Masami Hiramatsu (Google)
--
Masami Hiramatsu (Google)
0.stgit@devnote2/
>
> >
> > Again, just letting you know.
> >
> > -- Steve
--
Masami Hiramatsu (Google)
Let me gently ping :)
Let me check it should be rebased on tracing/for-next again. But basically
this should be the same...
On Sun, 18 Aug 2024 21:47:53 +0900
"Masami Hiramatsu (Google)" wrote:
> Hi,
>
> Here is the 13th version of the series to re-implement the fprobe
The subject has a typo, "tterating" -> "iterating".
I'll fix it and import this to probes/for-next.
Thank you,
On Sun, 18 Aug 2024 19:43:07 +0900
"Masami Hiramatsu (Google)" wrote:
> From: Masami Hiramatsu (Google)
>
> Add for_each_tracepoint
ote that there was already an implementation (see [1]), but for some
> reason it never made it.
>
> [1]
> https://lore.kernel.org/bpf/164338038439.242.17564843625400931820.stgit@devnote2/
> [2]
> https://lore.kernel.org/bpf/172562357215.467568.2172858907419105155.b4...@ellerman.id.au/
>
> >
> > -- Andrii
--
Masami Hiramatsu (Google)
re now:
>
> 0 - execute ret_handler (if it's defined)
> 1 - remove uprobe
> 2 - do nothing (ignore ret_handler)
>
> The session concept fits to our common use case where we do filtering
> on entry uprobe and based on the result we decide to run the return
> upro
5,7 @@ function_no_repeats_trace_call(unsigned long ip, unsigned
> long parent_ip,
> if (bit < 0)
> return;
>
> + parent_ip = function_get_true_parent_ip(parent_ip, fregs);
> cpu = smp_processor_id();
> data = per_cpu_ptr(tr->array_buffer.data, cpu);
> if (atomic_read(&data->disabled))
> @@ -356,6 +373,7 @@ function_stack_no_repeats_trace_call(unsigned long ip,
> unsigned long parent_ip,
>* recursive protection is performed.
>*/
> local_irq_save(flags);
> + parent_ip = function_get_true_parent_ip(parent_ip, fregs);
> cpu = raw_smp_processor_id();
> data = per_cpu_ptr(tr->array_buffer.data, cpu);
> disabled = atomic_inc_return(&data->disabled);
> --
> 2.34.1
>
--
Masami Hiramatsu (Google)
ollowing 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)
On Mon, 09 Sep 2024 10:16:55 +0200
Sven Schnelle wrote:
> Masami Hiramatsu (Google) writes:
>
> > On Fri, 6 Sep 2024 11:36:11 +0800
> > Zheng Yejian wrote:
> >
> >> On 2024/9/4 14:58, Sven Schnelle wrote:
> >> > Add a config option to disable/ena
l/trace/trace_output.h
> +++ b/kernel/trace/trace_output.h
> @@ -41,5 +41,14 @@ extern struct rw_semaphore trace_event_sem;
> #define SEQ_PUT_HEX_FIELD(s, x) \
> trace_seq_putmem_hex(s, &(x), sizeof(x))
>
> +#ifdef CONFIG_FUNCTION_TRACE_ARGS
> +void print_function_args(struct trace_seq *s, struct ftrace_regs *fregs,
> + unsigned long func);
> +#else
> +static inline void print_function_args(struct trace_seq *s, struct
> ftrace_regs *fregs,
> +unsigned long func) {
> + trace_seq_puts(s, "()");
> +}
> +#endif
> #endif
>
> --
> 2.43.0
>
--
Masami Hiramatsu (Google)
he trace option func-args (for
> > + the function tracer) and funcgraph-args (for the function graph
> > + tracer).
> > +
> > config DYNAMIC_FTRACE
> > bool "enable/disable function tracing dynamically"
> > depends on FUNCTION_TRACER
>
> --
> Thanks,
> Zheng Yejian
>
>
--
Masami Hiramatsu (Google)
mm, I thought the graph tracer depends on function tracer? Anyway, the
> configs should be cleaned up. I would like to make CONFIG_FTRACE just mean
> the function hook mechanism (mcount,fentry,etc) and not be used for the
> tracing system.
>
> Anyway, we can just make ftrace_regs defined outside any config for now.
>
> -- Steve
--
Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google)
Fix eventfs ownership testcase to find mount point if stat -c "%m" failed.
This can happen on the system based on busybox. In this case, this will
try to use the current working directory, which should be a tracefs top
directory (and eventfs is mounted
nhits;
> > > + int cpu;
> > >
> > > if (!is_trace_uprobe(ev))
> > > return 0;
> > >
> > > tu = to_trace_uprobe(ev);
> > > +
> > > + nhits = 0;
> > > + for_each_possible_cpu(cpu) {
> > > + nhits += per_cpu(*tu->nhits, cpu);
> > > + }
> > > +
> > > seq_printf(m, " %s %-44s %15lu\n", tu->filename,
> > > - trace_probe_name(&tu->tp), tu->nhit);
> > > +trace_probe_name(&tu->tp), nhits);
> > > return 0;
> > > }
> > >
> > > @@ -1512,7 +1529,8 @@ static int uprobe_dispatcher(struct uprobe_consumer
> > > *con, struct pt_regs *regs)
> > > int ret = 0;
> > >
> > > tu = container_of(con, struct trace_uprobe, consumer);
> > > - tu->nhit++;
> > > +
> > > + this_cpu_inc(*tu->nhits);
> > >
> > > udd.tu = tu;
> > > udd.bp_addr = instruction_pointer(regs);
> > > --
> > > 2.43.5
> > >
> >
> >
> > --
> > Masami Hiramatsu (Google)
> >
--
Masami Hiramatsu (Google)
c inline int init_test_probes(void)
> -{
> - return 0;
> -}
> -#endif /* CONFIG_KPROBES_SANITY_TEST */
> -
> extern int arch_prepare_kprobe(struct kprobe *p);
> extern void arch_arm_kprobe(struct kprobe *p);
> extern void arch_disarm_kprobe(struct kprobe *p);
> --
> 2.25.1
>
--
Masami Hiramatsu (Google)
On Sun, 25 Aug 2024 19:06:22 +0200
"Fernando F. Mancera" wrote:
> Hi,
>
> On 25/08/2024 09:41, Masami Hiramatsu (Google) wrote:
> > Hi,
> >
> > On Tue, 13 Aug 2024 13:25:40 -0400
> > Fernando Fernandez Mancera wrote:
> >
> >> When
memset(tp->args, 0, sizeof(tp->args[0]) * nargs);
> + memset(tp->args, 0, sizeof(tp->args[0]) * tp->nr_args);
>
> return 0;
>
--
Masami Hiramatsu (Google)
filter in user
> space, but that doesn't seem to be the case. I'll need to conduct further
> debugging, which might take some time.
>
> I also tried combining bpftrace with `perf trace`. Specifically, I used
> `perf trace` for PID1 and bpftrace for PID2. `perf trace` still only
> outputs events from PID1, but bpftrace prints events from both PIDs.
> I'm not yet sure why this is happening.
Yeah, if perf only reads the specific process's ring buffer, it should
work without this filter.
Thanks,
>
> Thanks so much,
--
Masami Hiramatsu (Google)
-
> kernel/trace/trace_uprobe.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
> index c98e3b3386ba..c7e2a0962928 100644
> --- a/kernel/trace/trace_uprobe.c
> +++ b/kernel/trace/trace_uprobe.c
> @@ -1443,6 +1443,9 @@ static void uretprobe_perf_func(struct trace_uprobe
> *tu, unsigned long func,
> struct pt_regs *regs,
> struct uprobe_cpu_buffer **ucbp)
> {
> + if (!uprobe_perf_filter(&tu->consumer, 0, current->mm))
> + return;
> +
> __uprobe_perf_func(tu, func, regs, ucbp);
> }
>
> --
> 2.34.1
>
--
Masami Hiramatsu (Google)
On Thu, 18 Jul 2024 13:30:57 -0500
Dan Carpenter wrote:
> Hello Masami Hiramatsu (Google),
>
> Commit 9d8616034f16 ("tracing/kprobes: Add symbol counting check when
> module loads") from Jul 5, 2024 (linux-next), leads to the following
> Smatch static checker warning
= container_of(tp, struct trace_uprobe, tp);
> WARN_ON(!uprobe_filter_is_empty(tu->tp.event->filter));
> @@ -1112,9 +1113,12 @@ static void __probe_event_disable(struct trace_probe
> *tp)
> if (!tu->inode)
> continue;
>
> - uprobe_unregister(tu->inode, tu->offset, &tu->consumer);
> + uprobe_unregister(tu->inode, tu->offset, &tu->consumer,
> URF_NO_SYNC);
> + sync = true;
> tu->inode = NULL;
> }
> + if (sync)
> + uprobe_unregister_sync();
> }
>
> static int probe_event_enable(struct trace_event_call *call,
--
Masami Hiramatsu (Google)
robes.c
> > > @@ -453,7 +453,7 @@ static int update_ref_ctr(struct uprobe *uprobe,
> > > struct mm_struct *mm,
> > > * @vaddr: the virtual address to store the opcode.
> > > * @opcode: opcode to be written at @vaddr.
> > > *
> > > - * Called with mm->mmap_lock held for write.
> > > + * Called with mm->mmap_lock held for read or write.
> > > * Return 0 (success) or a negative errno.
> > > */
> > > int uprobe_write_opcode(struct arch_uprobe *auprobe, struct mm_struct
> > > *mm,
> > > --
> > > 2.43.0
> > >
> >
> >
> > --
> > Masami Hiramatsu (Google)
--
Masami Hiramatsu (Google)
store the opcode.
> * @opcode: opcode to be written at @vaddr.
> *
> - * Called with mm->mmap_lock held for write.
> + * Called with mm->mmap_lock held for read or write.
> * Return 0 (success) or a negative errno.
> */
> int uprobe_write_opcode(struct arch_uprobe *auprobe, struct mm_struct *mm,
> --
> 2.43.0
>
--
Masami Hiramatsu (Google)
1 - 100 of 148 matches
Mail list logo