Re: [PATCH 1/2] objpool: enable inlining objpool_push() and objpool_pop() operations

graph tracer[1] which will make fprobe not using objpool. And also I'm planning to replace kretprobe with the new fprobe eventually. So if SLUB will use objpool for frontend caching, it sounds good to me. (Maybe it can speed up the object allocation/free) > > > > I'm testing an updated objpool in our HIDS project for critical pathes, > > which is widely deployed on servers inside my company. The new version > > eliminates the raw_local_irq_save and raw_local_irq_restore pair of > > objpool_push and gains up to 5% of performance boost. > > Mind Ccing me and linux-mm once you are posting that? Can you add me too? Thank you, > > Thanks, > Vlastimil > -- Masami Hiramatsu (Google)

Re: [PATCH] uprobes: prevent mutex_lock() under rcu_read_lock()

ong func, >struct uprobe_cpu_buffer **ucbp) > { > struct event_file_link *link; > + struct uprobe_cpu_buffer *ucb; > + > + ucb = prepare_uprobe_buffer(tu, regs, ucbp); > > rcu_read_lock(); > trace_probe_for_each_link_rcu(link, >tp) > - __uprobe_trace_func(tu, func, regs, ucbp, link->file); > + __uprobe_trace_func(tu, func, regs, ucb, link->file); > rcu_read_unlock(); > } > > -- > 2.43.0 > -- Masami Hiramatsu (Google)

Re: [PATCH 0/2] Objpool performance improvements

> > include/linux/objpool.h | 105 +++-- > lib/objpool.c | 112 +++- > 2 files changed, 107 insertions(+), 110 deletions(-) > > -- > 2.43.0 > -- Masami Hiramatsu (Google)

Re: [PATCH v4 2/2] rethook: honor CONFIG_FTRACE_VALIDATE_RCU_IS_WATCHING in rethook_try_get()

Thanks for update! This looks good to me. > > Thanks, Masami! Will you take it through your tree, or you'd like to > route it through bpf-next? OK, let me take it through linux-trace tree. Thank you! > > > > > Acked-by: Masami Hiramatsu (Google) > > &

Re: [PATCH v4 2/2] rethook: honor CONFIG_FTRACE_VALIDATE_RCU_IS_WATCHING in rethook_try_get()

which rely on rethook) runtime throughput > by 2.3%, according to BPF benchmarks ([0]). > > [0] > https://lore.kernel.org/bpf/caef4bzauq2wkmjzdc9s0rbwa01bybgwhn6andxqshyia47p...@mail.gmail.com/ > > Signed-off-by: Andrii Nakryiko Thanks for update! This looks good to m

Re: [PATCH v3 1/2] ftrace: make extra rcu_is_watching() validation check optional

rethook > infrastructure) runtime throughput by 2%, according to BPF benchmarks ([0]). > > [0] > https://lore.kernel.org/bpf/caef4bzauq2wkmjzdc9s0rbwa01bybgwhn6andxqshyia47p...@mail.gmail.com/ > This looks good to me :) Acked-by: Masami Hiramatsu (Google) Thank you, > Cc: S

Re: [PATCH v3 2/2] rethook: honor CONFIG_FTRACE_VALIDATE_RCU_IS_WATCHING in rethook_try_get()

claimed > @@ -174,6 +175,7 @@ struct rethook_node *rethook_try_get(struct rethook *rh) >*/ > if (unlikely(!rcu_is_watching())) > return NULL; > +#endif > > return (struct rethook_node *)objpool_pop(>pool); > } > -- > 2.43.0 > -- Masami Hiramatsu (Google)

Re: [PATCH v2] rethook: Remove warning messages printed for finding return address of a frame.

if (WARN_ON_ONCE(tsk != current && task_is_running(tsk))) > + if (tsk != current && task_is_running(tsk)) > return 0; > > do { > -- > 2.34.1 > -- Masami Hiramatsu (Google)

Re: [PATCH bpf-next] rethook: Remove warning messages printed for finding return address of a frame.

h Masami's tree, but the change makes > > sense to me, given this is an expected condition. > > > > Acked-by: Andrii Nakryiko > > Masami, I assume you'll pick this up? OK, anyway it will just return 0 if this situation happens, and caller will get the trampoline address instead of correct return address in this case. I think it does not do any unsafe things. So I agree removing it. But I think the explanation is a bit confusing. Thank you, > > Thanks, > Daniel -- Masami Hiramatsu (Google)

Re: [PATCH] ftrace: make extra rcu_is_watching() validation check optional

On Tue, 2 Apr 2024 22:21:00 -0700 Andrii Nakryiko wrote: > On Tue, Apr 2, 2024 at 9:00 PM Andrii Nakryiko > wrote: > > > > On Tue, Apr 2, 2024 at 5:52 PM Steven Rostedt wrote: > > > > > > On Wed, 3 Apr 2024 09:40:48 +0900 > > > Masami Hirama

Re: [PATCH] ftrace: make extra rcu_is_watching() validation check optional

: > > > > > > > On Mon, 1 Apr 2024 20:25:52 +0900 > > > > Masami Hiramatsu (Google) wrote: > > > > > > > > > > Masami, > > > > > > > > > > > > Are you OK with just keeping it set to N. > &

Re: [PATCH] ftrace: make extra rcu_is_watching() validation check optional

On Mon, 1 Apr 2024 12:09:18 -0400 Steven Rostedt wrote: > On Mon, 1 Apr 2024 20:25:52 +0900 > Masami Hiramatsu (Google) wrote: > > > > Masami, > > > > > > Are you OK with just keeping it set to N. > > > > OK, if it is only for the debugging,

Re: [PATCH] ftrace: make extra rcu_is_watching() validation check optional

Thanks! > > Masami, > > Are you OK with just keeping it set to N. OK, if it is only for the debugging, I'm OK to set N this. > > We could have other options like PROVE_LOCKING enable it. Agreed (but it should say this is a debug option) Thank you, > > -- Steve -- Masami Hiramatsu (Google)

Re: [PATCH] ftrace: make extra rcu_is_watching() validation check optional

checks to make sure RCU is on when ftrace callbacks recurse. > + > + This will add more overhead to all ftrace-based invocations. ... invocations, but keep it safe. > + > + If unsure, say N If unsure, say Y Thank you, > + > config RING_BUFFER_RECORD_RECURSION > bool "Record functions that recurse in the ring buffer" > depends on FTRACE_RECORD_RECURSION > -- > 2.43.0 > -- Masami Hiramatsu (Google)

Re: [PATCH] tracing: probes: Fix to zero initialize a local variable

On Wed, 20 Mar 2024 09:27:49 -0400 Steven Rostedt wrote: > On Wed, 20 Mar 2024 17:10:38 +0900 > "Masami Hiramatsu (Google)" wrote: > > > From: Masami Hiramatsu (Google) > > > > Fix to initialize 'val' local variable with zero. > > Dan reported that

[PATCH] tracing: probes: Fix to zero initialize a local variable

From: Masami Hiramatsu (Google) Fix to initialize 'val' local variable with zero. Dan reported that Smatch static code checker reports an error that a local 'val' variable needs to be initialized. Actually, the 'val' is expected to be initialized by FETCH_OP_ARG in the same loop

Re: [bug report] tracing/probes: Support $argN in return probe (kprobe and fprobe)

On Tue, 19 Mar 2024 10:10:00 -0400 Steven Rostedt wrote: > On Tue, 19 Mar 2024 10:19:09 +0300 > Dan Carpenter wrote: > > > Hello Masami Hiramatsu (Google), > > > > Commit 25f00e40ce79 ("tracing/probes: Support $argN in return probe > > (kprobe and

Re: tprobe event tracing error

ernel config in the attachment. > I noticed that you are developing event tracing tprobe subsystem. > May be you could explain such behavior? > Thank you in advance! >   > -- > Best regards > Maksim Morskov -- Masami Hiramatsu (Google)

Re: Sleepable kprobes

hat can I push this? (beside support more archs, > support LKM symbols, blacklist symbols, …). > > Thanks for your time and looking forward to your reply, > Tomer Samara, -- Masami Hiramatsu (Google)

Re: [PATCH 3/3] locking/atomic: openrisc: use generic_cmpxchg[64]_local for arch_cmpxchg[64]_local

blems if you end up doing operations on both > > the entire word and a sub-unit of the same thing. > > Thank you for pointing out this. I'll do some research on these > implementations. arc also has the LL-SC instruction but depends on the core feature, so I think we can use it. Thank you, > > > Arnd > > Regards, > wuqiang > -- Masami Hiramatsu (Google)

Re: [PATCH] tracing/kprobes: Fix symbol counting logic by looking at modules as well

On Sat, 28 Oct 2023 10:41:44 +0900 Masami Hiramatsu (Google) wrote: > Hi, > > On Fri, 27 Oct 2023 16:31:26 -0700 > Andrii Nakryiko wrote: > > > Recent changes to count number of matching symbols when creating > > a kprobe event failed to take

Re: [PATCH] tracing/kprobes: Fix symbol counting logic by looking at modules as well

t; > - count = 0; > - kallsyms_on_each_match_symbol(count_symbols, func_name, ); > + module_kallsyms_on_each_symbol(NULL, count_mod_symbols, ); > > - return count; > + return ctx.count; > } > > static int __trace_kprobe_create(int argc, const char *argv[]) > -- > 2.34.1 > -- Masami Hiramatsu (Google)

Re: [PATCH] tracing/kprobes: Fix symbol counting logic by looking at modules as well

org > > Cc: Masami Hiramatsu > > Cc: Steven Rostedt > > Fixes: b022f0c7e404 ("tracing/kprobes: Return EADDRNOTAVAIL when func > > matches several symbols") > > Signed-off-by: Andrii Nakryiko > > Acked-by: Song Liu Good catch! Thanks! -- Masami Hiramatsu (Google)

Re: [PATCH v6 0/2] Return EADDRNOTAVAIL when func matches several symbols during kprobe creation

when func matches several > symbols > selftests/ftrace: Add new test case which checks non unique symbol > > kernel/trace/trace_kprobe.c | 63 +++ > kernel/trace/trace_probe.h| 1 + > .../test.d/kprobe/kprobe_non_uniq_symbol.tc | 13 > 3 files changed, 77 insertions(+) > create mode 100644 > tools/testing/selftests/ftrace/test.d/kprobe/kprobe_non_uniq_symbol.tc > > Best regards and thank you in advance. > --- > [1]: > https://lore.kernel.org/lkml/20230816163517.112518-1-flan...@linux.microsoft.com/ > [2]: > https://lore.kernel.org/lkml/20230819101105.b0c104ae4494a7d1f2eea...@kernel.org/ > -- > 2.34.1 > -- Masami Hiramatsu (Google)

Re: [PATCH v5 0/2] Return EADDRNOTAVAIL when func matches several symbols during kprobe creation

On Thu, 19 Oct 2023 09:51:04 -0400 Steven Rostedt wrote: > On Thu, 19 Oct 2023 21:18:43 +0900 > Masami Hiramatsu (Google) wrote: > > > > So why is this adding stable? (and as Greg's form letter states, that's > > > not > > > how you do that) > > &g

Re: [PATCH v5 0/2] Return EADDRNOTAVAIL when func matches several symbols during kprobe creation

address may NOT be the instruction boundary. To avoid this issue, it should check the given symbol is unique. Thank you, > > -- Steve -- Masami Hiramatsu (Google)

Re: [PATCH] riscv: ftrace: Fix to pass correct ftrace_regs to ftrace_func_t functions

Hi, Sorry please ignore this. I found that the arch/riscv doesn't support HAVE_DYNAMIC_FTRACE_WITH_ARGS. Thus this might add a new feature support. Let me update it. Thank you, On Sun, 15 Oct 2023 23:15:23 +0900 Masami Hiramatsu (Google) wrote: > Hi, > > Gentry ping. > > I th

Re: [PATCH] riscv: ftrace: Fix to pass correct ftrace_regs to ftrace_func_t functions

Hi, Gentry ping. I think this should be an important fix because if a fprobe handler without FTRACE_OPS_FL_SAVE_REGS tries to access any register via ftrace_regs, that will get a wrong value. Thank you, On Mon, 2 Oct 2023 21:50:34 +0900 "Masami Hiramatsu (Google)" wrote: >

[PATCH] riscv: ftrace: Fix to pass correct ftrace_regs to ftrace_func_t functions

From: Masami Hiramatsu (Google) Since ftrace_func_t requires to pass 'struct ftrace_regs *' as the 4th argument even if FTRACE_OPS_FL_SAVE_REGS is not set, ftrace_caller must pass 'struct ftrace_regs *', which is a partial pt_regs, on the stack to the ftrace_func_t functions, so

Re: [PATCH v5] eventfs: Fix the NULL pointer dereference bug in eventfs_remove_rec()

0c0 from 0xffff80008000 > PHYS_OFFSET: 0xcc5b8000 > CPU features: 0x88000203,3c02,1000421b > Memory Limit: none > Rebooting in 1 seconds.. > This looks good to me! Acked-by: Masami Hiramatsu (Google) Thanks! > Fixes: 5bdcd5f5331a ("eventfs: Implemen

Re: [PATCH v3] eventfs: Fix the NULL pointer dereference bug in eventfs_remove_rec()

x384b00c0 from 0x80008000 > PHYS_OFFSET: 0xcc5b8000 > CPU features: 0x88000203,3c02,1000421b > Memory Limit: none > Rebooting in 1 seconds.. > > Fixes: 5bdcd5f5331a ("eventfs: Implement removal of meta data from eventfs") > Signed-off-by