Re: [PATCHv2 1/3] uprobe: Add uretprobe syscall to speed up return probe

tomic_set(>slot_count, 1); > - arch_uprobe_copy_ixol(area->pages[0], 0, , UPROBE_SWBP_INSN_SIZE); > + insns = arch_uprobe_trampoline(_size); > + arch_uprobe_copy_ixol(area->pages[0], 0, insns, insns_size); > > if (!xol_add_vma(mm, area)) > return area; > @@ -2123,7 +2133,7 @@ static struct return_instance > *find_next_ret_chain(struct return_instance *ri) > return ri; > } > > -static void handle_trampoline(struct pt_regs *regs) > +void uprobe_handle_trampoline(struct pt_regs *regs) > { > struct uprobe_task *utask; > struct return_instance *ri, *next; > @@ -2188,7 +2198,7 @@ static void handle_swbp(struct pt_regs *regs) > > bp_vaddr = uprobe_get_swbp_addr(regs); > if (bp_vaddr == get_trampoline_vaddr()) > - return handle_trampoline(regs); > + return uprobe_handle_trampoline(regs); > > uprobe = find_active_uprobe(bp_vaddr, _swbp); > if (!uprobe) { > diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c > index faad00cce269..be6195e0d078 100644 > --- a/kernel/sys_ni.c > +++ b/kernel/sys_ni.c > @@ -391,3 +391,5 @@ COND_SYSCALL(setuid16); > > /* restartable sequence */ > COND_SYSCALL(rseq); > + > +COND_SYSCALL(uretprobe); > -- > 2.44.0 > -- Masami Hiramatsu (Google)

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: [RFC PATCH] ftrace: riscv: move from REGS to ARGS

gt; +static __always_inline unsigned long > > +ftrace_regs_get_return_value(const struct ftrace_regs *fregs) > > +{ > > + return fregs->a0; > > +} > > + > > +static __always_inline void > > +ftrace_regs_set_return_value(struct ftrace_regs *fregs, > > +unsigned long ret) > > +{ > > + fregs->a0 = ret; > > +} > > + > > +static __always_inline void > > +ftrace_override_function_with_return(struct ftrace_regs *fregs) > > +{ > > + fregs->epc = fregs->ra; > > +} > > Style/nit: All above; Try to use the full 100 chars, and keep the > function name return value on the same line for grepability. > > > Björn > > [1] > https://lore.kernel.org/all/170887410337.564249.6360118840946697039.stgit@devnote2/ -- Masami Hiramatsu (Google)

Re: [PATCHv2 1/3] uprobe: Add uretprobe syscall to speed up return probe

ul in practice. > > > > I think at least it should check the caller address to ensure the > > address is in the trampoline. > > But anyway, uprobes itself can break the target process, so no one > > might care if this system call breaks the process now. > > If we already have an expected range of addresses, then I think it's > fine to do a quick unlikely() check. I'd be more concerned if we need > to do another lookup or search to just validate this. I'm sure Jiri > will figure it out. Good. > > > > > > > > > Also note that sys_uretprobe is a kind of internal and unstable API > > > and it is explicitly called out that its contract can change at any > > > time and user space shouldn't rely on it. It's purely for the kernel's > > > own usage. > > > > Is that OK to use a syscall as "internal" and "unstable" API? > > See above about rt_sigreturn. It seems like yes, for some highly > specialized syscalls it is the case already. OK, but as I said it is just for performance optimization, that is a bit different from rt_sigreturn case. Thank you, > > > > > > > > So let's please keep it fast and simple. > > > > > > > > > > Thank you, > > > > > > > > > > > > > > > > > > thanks, > > > > > jirka > > > > > > > > > > > > > > > > > > > > > > [...] > > > > > > ([OT] If we can add syscall so casually, I would like to add sys_traceevent > > for recording user space events :-) .) > > Have you proposed this upstream? :) I have no clue and no opinion about it... > > > > > -- > > Masami Hiramatsu (Google) -- Masami Hiramatsu (Google)

Re: [PATCHv2 1/3] uprobe: Add uretprobe syscall to speed up return probe

peration strictly. > > > > > I concern that new system calls introduce vulnerabilities. > > > > > > > > > > > > > As Oleg and Jiri mentioned, this syscall can't harm kernel or other > > > > processes, only the process that is abusing the API. So any extra > > > > checks that would slow down this approach is an unnecessary overhead > > > > and complication that will never be useful in practice. > > > > > > I think at least it should check the caller address to ensure the > > > address is in the trampoline. > > > But anyway, uprobes itself can break the target process, so no one > > > might care if this system call breaks the process now. > > > > If we already have an expected range of addresses, then I think it's > > fine to do a quick unlikely() check. I'd be more concerned if we need > > to do another lookup or search to just validate this. I'm sure Jiri > > will figure it out. > > Oleg mentioned the trampoline address check could race with another > thread's mremap call, however trap is using that check as well, it > still seems like good idea to do it also in the uretprobe syscall Yeah, and also, can we add a stack pointer check if the trampoline is shared with other probe points? Thank you, > > jirka -- Masami Hiramatsu (Google)

Re: [PATCH] tracing: Add new_exec tracepoint

nt using "perf probe" tool. Thank you, > > I don't know if "common" is the right question here, because it's a > chicken-egg problem: no tracepoint, we give up; we have the > tracepoint, it unlocks a range of new use cases (that require robust > solution to make BPF programs exec-aware, and a tracepoint is the only > option IMHO). > > Thanks, > -- Marco -- Masami Hiramatsu (Google)

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 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] ring-buffer: Only update pages_touched when a new page is touched

On Tue, 9 Apr 2024 15:13:09 -0400 Steven Rostedt wrote: > From: "Steven Rostedt (Google)" > > The "buffer_percent" logic that is used by the ring buffer splice code to > only wake up the tasks when there's no data after the buffer is filled to > the perc

Re: [PATCH v2] tracing: Add sched_prepare_exec tracepoint

80.048580: sched_prepare_exec: interp=/bin/bash > filename=/bin/bash pid=381 comm=sshd > <...>-385 [001] . 180.068277: sched_prepare_exec: > interp=/usr/bin/tty filename=/usr/bin/tty pid=385 comm=bash > <...>-389 [006] . 192.020147: sched_prepare_exec: > interp=/u

Re: [PATCH] init/main.c: Remove redundant space from saved_command_line

e > > trailing space */ > > } > > } > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68korg > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like > that. > -- Linus Torvalds > -- Masami Hiramatsu (Google)

Re: Copying TLS/user register data per perf-sample?

however, we have > environments where eBPF is not available. > > It's sounding like to do this properly without eBPF a new feature would > be required. If so, I do have some patches I can share in a bit as an > RFC. It is better to be shared in RFC stage, so that we can discuss it from the direction level. Thank you, > > Thanks, > -Beau > > > Thank you, > > > > -- > > Masami Hiramatsu (Google) -- Masami Hiramatsu (Google)

Re: [PATCH] init/main.c: Remove redundant space from saved_command_line

On Thu, 11 Apr 2024 23:29:40 +0800 Yuntao Wang wrote: > On Thu, 11 Apr 2024 23:07:45 +0900, Masami Hiramatsu (Google) > wrote: > > > On Thu, 11 Apr 2024 09:19:32 +0200 > > Geert Uytterhoeven wrote: > > > > > CC Hiramatsu-san (now for real :-) > >

Re: [PATCH RESEND] bootconfig: use memblock_free_late to free xbc memory to buddy

onfig.c > @@ -63,7 +63,7 @@ static inline void * __init xbc_alloc_mem(size_t size) > > static inline void __init xbc_free_mem(void *addr, size_t size) > { > - memblock_free(addr, size); > + memblock_free_late(__pa(addr), size); > } > > #else /* !__KERNEL__ */ > -- > 2.39.2 > > -- Masami Hiramatsu (Google)

Re: [PATCH v2] init/main.c: Remove redundant space from saved_command_line

args to make the string in saved_command_line look more perfect. > > Signed-off-by: Yuntao Wang OK, this looks good to me. Acked-by: Masami Hiramatsu (Google) Let me pick this to bootconfig/for-next. Thank you, > --- > v1 -> v2: Fix the issue using the method suggested by M

Re: Copying TLS/user register data per perf-sample?

possible via some other means? It'd be great to be able > to do this directly at the perf_event sample via the ABI or a probe. > Have you tried to use uprobes? It should be able to access user-space registers including fs/gs. Thank you, -- Masami Hiramatsu (Google)

Re: [PATCH] tracing: Add new_exec tracepoint

t; + __string( comm, task->comm ) > + ), > + > + TP_fast_assign( > + __assign_str(filename, bprm->filename); > + __entry->pid = task->pid; > + __assign_str(comm, task->comm); > + ), > + > + TP_printk("filename=%s pid=%d comm=%s", > + __get_str(filename), __entry->pid, __get_str(comm)) > +); > + > #endif > > /* This part must be outside protection */ > -- > 2.44.0.478.gd926399ef9-goog > -- Masami Hiramatsu (Google)

Re: [PATCH v3] kprobes: Fix possible use-after-free issue on kprobe registration

goto out; > } > > - /* Check if 'p' is probing a module. */ > - *probed_mod = __module_text_address((unsigned long) p->addr); > + /* Get module refcount and reject __init functions for loaded modules. > */ > if (*probed_mod) { > /* >* We must hold a refcount of the probed module while updating > -- > 2.25.1 > -- Masami Hiramatsu (Google)

Re: [PATCH] uprobes: reduce contention on uprobes_tree access

gt; > > > > > > > > *uprobe) > > > > > > > > > > if (WARN_ON(!uprobe_is_active(uprobe))) > > > > > > > > > > return; > > > > > > > > > > > > > > > > > > > > - spin_lock(_treelock); > > > > > > > > > > + write_lock(_treelock); > > > > > > > > > > rb_erase(>rb_node, _tree); > > > > > > > > > > - spin_unlock(_treelock); > > > > > > > > > > + write_unlock(_treelock); > > > > > > > > > > RB_CLEAR_NODE(>rb_node); /* for > > > > > > > > > > uprobe_is_active() */ > > > > > > > > > > put_uprobe(uprobe); > > > > > > > > > > } > > > > > > > > > > @@ -1298,7 +1298,7 @@ static void build_probe_list(struct > > > > > > > > > > inode *inode, > > > > > > > > > > min = vaddr_to_offset(vma, start); > > > > > > > > > > max = min + (end - start) - 1; > > > > > > > > > > > > > > > > > > > > - spin_lock(_treelock); > > > > > > > > > > + read_lock(_treelock); > > > > > > > > > > n = find_node_in_range(inode, min, max); > > > > > > > > > > if (n) { > > > > > > > > > > for (t = n; t; t = rb_prev(t)) { > > > > > > > > > > @@ -1316,7 +1316,7 @@ static void build_probe_list(struct > > > > > > > > > > inode *inode, > > > > > > > > > > get_uprobe(u); > > > > > > > > > > } > > > > > > > > > > } > > > > > > > > > > - spin_unlock(_treelock); > > > > > > > > > > + read_unlock(_treelock); > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > /* @vma contains reference counter, not the probed > > > > > > > > > > instruction. */ > > > > > > > > > > @@ -1407,9 +1407,9 @@ vma_has_uprobes(struct vm_area_struct > > > > > > > > > > *vma, unsigned long start, unsigned long e > > > > > > > > > > min = vaddr_to_offset(vma, start); > > > > > > > > > > max = min + (end - start) - 1; > > > > > > > > > > > > > > > > > > > > - spin_lock(_treelock); > > > > > > > > > > + read_lock(_treelock); > > > > > > > > > > n = find_node_in_range(inode, min, max); > > > > > > > > > > - spin_unlock(_treelock); > > > > > > > > > > + read_unlock(_treelock); > > > > > > > > > > > > > > > > > > > > return !!n; > > > > > > > > > > } > > > > > > > > > > -- > > > > > > > > > > 2.43.0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Masami Hiramatsu (Google) > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Masami Hiramatsu (Google) > > > > > > > > > > > > > > > -- > > > > > Masami Hiramatsu (Google) > > > > > > -- > > Masami Hiramatsu (Google) -- Masami Hiramatsu (Google)

Re: [PATCH] tracing: Limit trace_seq size to just 8K and not depend on architecture PAGE_SIZE

On Mon, 4 Mar 2024 19:13:42 -0500 Steven Rostedt wrote: > From: "Steven Rostedt (Google)" > > The trace_seq buffer is used to print out entire events. It's typically > set to PAGE_SIZE * 2 as there's some events that can be quite large. > > As a side effect, write

Re: [PATCH v2] bootconfig: use memblock_free_late to free xbc memory to buddy

6605] 88845dd30100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff > [9.654675] > == > > Cc: sta...@vger.kernel.org > Signed-off-by: Qiang Zhang Looks good to me. Acked-by: Masami Hiramatsu (Google)

Re: [PATCH v2] bootconfig: use memblock_free_late to free xbc memory to buddy

h this fix? Thank you, On Fri, 12 Apr 2024 22:18:20 +0900 Masami Hiramatsu (Google) wrote: > On Fri, 12 Apr 2024 18:49:41 +0800 > qiang4.zh...@linux.intel.com wrote: > > > From: Qiang Zhang > > > > On the time to free xbc memory in xbc_exit(), memblock may has handed >

Re: [PATCH for-next v2] tracing/kprobes: Add symbol counting check when module loads

On Tue, 16 Apr 2024 00:47:26 -0400 Steven Rostedt wrote: > On Mon, 15 Apr 2024 18:40:23 +0900 > "Masami Hiramatsu (Google)" wrote: > > > Check the number of probe target symbols in the target module when > > the module is loaded. If the probe is not on the unique

Re: [PATCH for-next v2] tracing/kprobes: Add symbol counting check when module loads

Sorry, this is actually v3. (miss-configured...) Thanks, On Thu, 18 Apr 2024 05:46:34 +0900 "Masami Hiramatsu (Google)" wrote: > From: Masami Hiramatsu (Google) > > Currently, kprobe event checks whether the target symbol name is unique > or not, so that i

Re: [PATCH v4 05/15] mm: introduce execmem_alloc() and execmem_free()

l be used to identify the calling subsystem and to > allow architectures define parameters for ranges suitable for that > subsystem. > This looks good to me for the kprobe part. Acked-by: Masami Hiramatsu (Google) Thank you, > Signed-off-by: Mike Rapoport (IBM) > --- > arc

Re: [PATCH v4 05/15] mm: introduce execmem_alloc() and execmem_free()

module_alloc(). However, if an architecture only supports breakpoint/trap based kprobe, it does not need to consider whether the execmem is allocated. > > We can always share large ROX pages as long as they are within the correct > address space. The permissions for them are ROX and the alignment > differences are due to KASAN and this is handled during allocation of the > large page to refill the cache. __execmem_cache_alloc() only needs to limit > the search for the address space of the range. So I don't think EXECMEM_KPROBE always same as EXECMEM_MODULE_TEXT, it should be configured for each arch. Especially, if it is only used for searching parameter, it looks OK to me. Thank you, > > And regardless, they way we deal with sharing of the cache can be sorted > out later. > > > Thanks, > > Song > > -- > Sincerely yours, > Mike. > -- Masami Hiramatsu (Google)

Re: [PATCH v9 07/36] function_graph: Allow multiple users to attach to function graph

On Fri, 19 Apr 2024 23:52:58 -0400 Steven Rostedt wrote: > On Mon, 15 Apr 2024 21:50:20 +0900 > "Masami Hiramatsu (Google)" wrote: > > > @@ -27,23 +28,157 @@ > > > > #define FGRAPH_RET_SIZE sizeof(struct ftrace_ret_stack) > > #define FGRAPH_RET

Re: [PATCH v4 14/15] kprobes: remove dependency on CONFIG_MODULES

NG) { > ... > } > > so moving out 'enum module_state' won't be enough. Hmm, this part should be inline functions like; #ifdef CONFIG_MODULES static inline bool module_is_coming(struct module *mod) { return mod->state == MODULE_STATE_COMING; } #else #define module_is_coming(mod) (false) #endif Then we don't need the enum. Thank you, > > > > > > >> -- > > >> Masami Hiramatsu > > > > > -- > Sincerely yours, > Mike. > -- 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] uprobes: reduce contention on uprobes_tree access

> > > > > > > - spin_lock(_treelock); > > > > > > > > > > > > + write_lock(_treelock); > > > > > > > > > > > > u = __insert_uprobe(uprobe); > > > > > > > > > > > > - spin_unlock(_tr

Re: [PATCH 1/2] tracing/user_events: Fix non-spaced field matching

Ah, nevermind. Synthetic event parses the field by strsep(';') first and argv_split(). So it does not have this issue. Thank you, > > Thanks, > -Beau > > > > + /* We must fixup 'field;field' to 'field; field' */ > > > + char *fixed = fix_semis_no_space(args, count); > > > + char **split; > > > + > > > + if (!fixed) > > > + return NULL; > > > + > > > + /* We do a normal split afterwards */ > > > + split = argv_split(GFP_KERNEL, fixed, argc); > > > + > > > + /* We can free since argv_split makes a copy */ > > > + kfree(fixed); > > > + > > > + return split; > > > + } > > > + > > > + /* No fixup is required */ > > > + return argv_split(GFP_KERNEL, args, argc); > > > +} > > > + > > > /* > > > * Parses the event name, arguments and flags then registers if > > > successful. > > > * The name buffer lifetime is owned by this method for success cases > > > only. > > > @@ -2012,7 +2098,7 @@ static int user_event_parse(struct user_event_group > > > *group, char *name, > > > return -EPERM; > > > > > > if (args) { > > > - argv = argv_split(GFP_KERNEL, args, ); > > > + argv = user_event_argv_split(args, ); > > > > > > if (!argv) > > > return -ENOMEM; > > > -- > > > 2.34.1 > > > > > > > > > -- > > Masami Hiramatsu (Google) -- 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: [PATCHv3 bpf-next 0/7] uprobe: uretprobe speed up

d! I reviewed the series and just except for the manpage, it looks good to me. Reviewed-by: Masami Hiramatsu (Google) for the series. If Linux API maintainers are OK, I can pick this in probes/for-next. (BTW, who will pick the manpage patch?) Thank you, > > v3 changes: > - adde

Re: [PATCH 7/7] man2: Add uretprobe syscall page

NOTES > +.BR uretprobe() > +exists only to allow the invocation of return uprobe consumers. > +It should > +.B never > +be called directly. > +Details of the arguments (if any) passed to > +.BR uretprobe () > +and the return value are specific for given architecture. > -- > 2.44.0 > -- Masami Hiramatsu (Google)

Re: [PATCH v5 14/15] kprobes: remove dependency on CONFIG_MODULES

n non-modular kernels. > > Add #ifdef CONFIG_MODULE guards for the code dealing with kprobes inside > modules, make CONFIG_KPROBES select CONFIG_EXECMEM and drop the > dependency of CONFIG_KPROBES on CONFIG_MODULES. Looks good to me. Acked-by: Masami Hiramatsu (Google) Thank y

Re: [PATCH v2] uprobes: reduce contention on uprobes_tree access

d - start) - 1; > > > > - spin_lock(_treelock); > > + read_lock(_treelock); > > n = find_node_in_range(inode, min, max); > > if (n) { > > for (t = n; t; t = rb_prev(t)) { > > @@ -1316,7 +1316,7 @@ static void build_probe_list(struct inode *inode, > > get_uprobe(u); > > } > > } > > - spin_unlock(_treelock); > > + read_unlock(_treelock); > > } > > > > /* @vma contains reference counter, not the probed instruction. */ > > @@ -1407,9 +1407,9 @@ vma_has_uprobes(struct vm_area_struct *vma, unsigned > > long start, unsigned long e > > min = vaddr_to_offset(vma, start); > > max = min + (end - start) - 1; > > > > - spin_lock(_treelock); > > + read_lock(_treelock); > > n = find_node_in_range(inode, min, max); > > - spin_unlock(_treelock); > > + read_unlock(_treelock); > > > > return !!n; > > } > > -- > > 2.43.0 > > > -- Masami Hiramatsu (Google)

Re: [PATCH v2] uprobes: reduce contention on uprobes_tree access

_list(struct inode *inode, > get_uprobe(u); > } > } > - spin_unlock(_treelock); > + read_unlock(_treelock); > } > > /* @vma contains reference counter, not the probed instruction. */ > @@ -1407,9 +1407,9 @@ vma_has_uprobes(struct vm_area_struct *vma, unsigned > long start, unsigned long e > min = vaddr_to_offset(vma, start); > max = min + (end - start) - 1; > > - spin_lock(_treelock); > + read_lock(_treelock); > n = find_node_in_range(inode, min, max); > - spin_unlock(_treelock); > + read_unlock(_treelock); > > return !!n; > } > -- > 2.43.0 > -- Masami Hiramatsu (Google)

Re: [PATCH 1/2] tracing/user_events: Fix non-spaced field matching

r is copied from user > to kernel, so it cannot change (and no other threads access it). I also > checked trace_parse_run_command() which is the same. So at least in this > context the non-atomic part is OK. Oh, sorry if I scared you. I've seen bugs get introduced into loops like this many times (while updating the code), so I try to keep it simple. I'm sure that your code has no bugs. Thank you, -- Masami Hiramatsu (Google)

Re: [PATCH v3] bootconfig: use memblock_free_late to free xbc memory to buddy

6605] 88845dd30100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff > [9.654675] > == > > Cc: sta...@vger.kernel.org > Signed-off-by: Qiang Zhang Looks good to me. Acked-by: Masami Hiramatsu (Goo

Re: [PATCH v9 01/36] tracing: Add a comment about ftrace_regs definition

On Wed, 24 Apr 2024 15:19:24 +0200 Florent Revest wrote: > On Wed, Apr 24, 2024 at 2:23 PM Florent Revest wrote: > > > > On Mon, Apr 15, 2024 at 2:49 PM Masami Hiramatsu (Google) > > wrote: > > > > > > From: 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] kernel/trace/trace_probe:Fixed memory leak issues in trace_probe.c.

goto fail; > } > snprintf(parg->fmt, len, "%s[%d]", parg->type->fmttype, >parg->count); > -- > 2.25.1 > -- Masami Hiramatsu (Google)

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

is quite a refactoring :) > > On Mon, Apr 15, 2024 at 2:49 PM Masami Hiramatsu (Google) > wrote: > > > > Hi, > > > > Here is the 9th version of the series to re-implement the fprobe on > > function-graph tracer. The previous version is; > > > >

Re: [PATCH 1/2] tracing/user_events: Fix non-spaced field matching

v_split(GFP_KERNEL, args, argc); > +} > + > /* > * Parses the event name, arguments and flags then registers if successful. > * The name buffer lifetime is owned by this method for success cases only. > @@ -2012,7 +2098,7 @@ static int user_event_parse(struct user_event_group > *group, char *name, > return -EPERM; > > if (args) { > - argv = argv_split(GFP_KERNEL, args, ); > + argv = user_event_argv_split(args, ); > > if (!argv) > return -ENOMEM; > -- > 2.34.1 > -- Masami Hiramatsu (Google)

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

Hi Steve, Can you review this series? Especially, [07/36] and [12/36] has been changed a lot from your original patch. Thank you, On Mon, 15 Apr 2024 21:48:59 +0900 "Masami Hiramatsu (Google)" wrote: > Hi, > > Here is the 9th version of the series to re-implement the f

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

changes) > > > > > > > > On the other hand, multi-kretprobes got significantly faster (+24%!). > > > Again, I don't know if it is expected or not, but it's a nice > > > improvement. > > > > Thanks! > > > > > > > > If you have

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

iles changed, 2325 insertions(+), 882 deletions(-) > > create mode 100644 > > tools/testing/selftests/ftrace/test.d/dynevent/add_remove_fprobe_repeat.tc > > > > -- > > Masami Hiramatsu (Google) > > -- Masami Hiramatsu (Google)

Re: [PATCH v3] tracing/probes: Fix memory leak in traceprobe_parse_probe_arg_body()

freed in this case and leaks its memory. > > Thus jump to the label 'fail' in that error case. > Looks good to me. Acked-by: Masami Hiramatsu (Google) Thank you! > Fixes: 032330abd08b ("tracing/probes: Cleanup probe argument parser") > Signed-off-by: LuMingYin > ---

Re: [PATCH v9 29/36] bpf: Enable kprobe_multi feature if CONFIG_FPROBE is enabled

On Thu, 25 Apr 2024 13:09:32 -0700 Andrii Nakryiko wrote: > On Mon, Apr 15, 2024 at 6:22 AM Masami Hiramatsu (Google) > wrote: > > > > From: Masami Hiramatsu (Google) > > > > Enable kprobe_multi feature if CONFIG_FPROBE is enabled. The pt_regs is

Re: [PATCH v9 36/36] fgraph: Skip recording calltime/rettime if it is not nneeded

On Thu, 25 Apr 2024 13:15:08 -0700 Andrii Nakryiko wrote: > On Mon, Apr 15, 2024 at 6:25 AM Masami Hiramatsu (Google) > wrote: > > > > From: Masami Hiramatsu (Google) > > > > Skip recording calltime and rettime if the fgraph_ops does not need it. > > This i

Re: [PATCH] eventfs/tracing: Add callback for release of an eventfs_inode

On Tue, 30 Apr 2024 14:23:27 -0400 Steven Rostedt wrote: > From: "Steven Rostedt (Google)" > > Synthetic events create and destroy tracefs files when they are created > and removed. The tracing subsystem has its own file descriptor > representing the state of the event

Re: [PATCH resend ftrace] Asynchronous grace period for register_ftrace_direct()

hen adding a new direct trampoline. This looks good to me. Reviewed-by: Masami Hiramatsu (Google) Thank you, > [1] https://lore.kernel.org/all/cover.1710877680.git@cloudflare.com/ > > Reported-by: Jakub Kicinski > Reported-by: Alexei Starovoitov > Reported-by: Chris Mason > S

Re: [v3] tracing/probes: Fix memory leak in traceprobe_parse_probe_arg_body()

ke to read any improved (patch) version descriptions (or > changelogs)? Thanks, but those are nitpicks and I don't mind it. Thank you, > > Regards, > Markus -- Masami Hiramatsu (Google)

Re: [PATCH RESEND v8 07/16] mm/execmem, arch: convert simple overrides of module_alloc to execmem

e does > not implement execmem_arch_setup(), execmem_alloc() will fall back to > module_alloc(). > Looks good to me. Reviewed-by: Masami Hiramatsu (Google) Thanks, > Signed-off-by: Mike Rapoport (IBM) > Acked-by: Song Liu > --- > arch/loongarch/kernel/module.c | 19 ++

Re: [PATCH RESEND v8 05/16] module: make module_memory_{alloc,free} more self-contained

On Sun, 5 May 2024 19:06:17 +0300 Mike Rapoport wrote: > From: "Mike Rapoport (IBM)" > > Move the logic related to the memory allocation and freeing into > module_memory_alloc() and module_memory_free(). > Looks good to me. Reviewed-by: Masami Hiramatsu (Google

Re: [PATCHv5 bpf-next 7/8] selftests/x86: Add return uprobe shadow stack test

> + uretprobe_trigger(); > + > + printf("[OK]\tUretprobe test\n"); > + err = 0; > + > +out: > + ARCH_PRCTL(ARCH_SHSTK_DISABLE, ARCH_SHSTK_SHSTK); > + signal(SIGSEGV, SIG_DFL); > + if (fd) > + close(fd); > + return err; > +} > + > void segv_handler_ptrace(int signum, siginfo_t *si, void *uc) > { > /* The SSP adjustment caused a segfault. */ > @@ -867,6 +1003,12 @@ int main(int argc, char *argv[]) > goto out; > } > > + if (test_uretprobe()) { > + ret = 1; > + printf("[FAIL]\turetprobe test\n"); > + goto out; > + } > + > return ret; > > out: > -- > 2.44.0 > -- Masami Hiramatsu (Google)

Re: [PATCHv5 bpf-next 6/8] x86/shstk: Add return uprobe support

r debugging. But I think that needs another series of patches. We also need to discuss when it should be prohibited and how (e.g. audit interface? SELinux?). But I think this series is just optimizing currently available uprobes with a new syscall. I don't think it changes such security concerning. Thank you, > > jirka -- Masami Hiramatsu (Google)

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

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

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

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: How to trace kvm:kvm_exit using fprobe?

-cmd: > > *trace-cmd stream -e kvm:kvm_exit* > But if I echo to dynamic_event will get "Invalid argument" error: > # cd /sys/kernel/debug/tracing > > *# echo 't:kvm kvm_exit' >> dynamic_events*-bash: echo: write error: > Invalid argument > > How to solve this problem? > > Thanks, > don -- Masami Hiramatsu (Google)

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

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 10/20] function_graph: Have the instances use their own ftrace_ops for filtering

> 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 10/20] function_graph: Have the instances use their own ftrace_ops for filtering

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

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] 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 v10 01/36] tracing: Add a comment about ftrace_regs definition

On Thu, 23 May 2024 19:10:31 -0400 Steven Rostedt wrote: > On Tue, 7 May 2024 23:08:12 +0900 > "Masami Hiramatsu (Google)" wrote: > > > From: Masami Hiramatsu (Google) > > > > To clarify what will be expected on ftrace_regs, add a comment to the &g

Re: [PATCH v10 03/36] x86: tracing: Add ftrace_regs definition in the header

On Thu, 23 May 2024 19:14:59 -0400 Steven Rostedt wrote: > On Tue, 7 May 2024 23:08:35 +0900 > "Masami Hiramatsu (Google)" wrote: > > > From: Masami Hiramatsu (Google) > > > > Add ftrace_regs definition for x86_64 in the ftrace header to > > cl

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

_FIELD); > return -ENOENT; > -- > 2.35.3 > -- Masami Hiramatsu (Google)

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

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] ftrace: Fix stack trace entry generated by ftrace_pid_func()

ACE_OPS_FL_PID) || !ops->private) >107return false; >108 >109tr = ops->private; >110 >111 return 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 19/20] function_graph: Use for_each_set_bit() in __ftrace_return_to_handler()

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_set_b

Re: [PATCH] kernel: trace: preemptirq_delay_test: add MODULE_DESCRIPTION()

On Sat, 18 May 2024 15:54:49 -0700 Jeff Johnson wrote: > Fix the 'make W=1' warning: > > WARNING: modpost: missing MODULE_DESCRIPTION() in > kernel/trace/preemptirq_delay_test.o > Looks good to me. Acked-by: Masami Hiramatsu (Google) Fixes: f96e8577da10 ("lib: Ad

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

e_probe_log_err(ctx->offset, NO_BTF_FIELD); > return -ENOENT; > -- > 2.35.3 > -- Masami Hiramatsu (Google)

Re: [PATCH v10 07/36] function_graph: Allow multiple users to attach to function graph

On Fri, 24 May 2024 21:32:08 -0400 Steven Rostedt wrote: > On Tue, 7 May 2024 23:09:22 +0900 > "Masami Hiramatsu (Google)" wrote: > > > @@ -109,6 +244,21 @@ ftrace_push_return_trace(unsigned long ret, unsigned > > long func, > > if (!current->

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

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

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

d 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_events/ftr

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 19/20] function_graph: Use for_each_set_bit() in __ftrace_return_to_handler()

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_set_b

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

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_array

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

nage. > > 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-off-by: Masami Hiram

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

he 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 > > [1] https://

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

-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/fprobe: S

Kernel syscall hooks

Hi, When the kernel gets a particular syscall, is there a way to get it to trigger another program? Or send it a signal? Thanks, The Nomad. _ Don't just search. Find. Check out the new MSN Search!

Keystroke simulator

Is there a way to simulate a keystroke to a program, ie. have a program send it something so that as far as it's concerned, say, the P key has been pressed? Thanks, The Nomad. _ Express yourself instantly with MSN Messenger!

Invitation to use Google Talk

--- You've been invited by Dula Dame to use Google Talk. If you already have a Google account, login to Gmail and accept this chat invitation: http://mail.google.com/mail/b-de9a2ad76d-397eb7cc5e-HsnrQQMRxQEBFT80ciL5NgGAPOc

GOOGLE Gewinnbenachrichtigung!!!

GOOGLE INTERNATIONALE Förderung-GEWINNZUTEILUNG GOOGLE Förderung GOOGLE Einarbeitung© UROPA INTERLOTTO/EUROMILLINEN LOTTO BONUS-PROGRAMM BEL-GRAVE HOUSE, 76 BUCKINGHAM PALACE ROAD, LONDON SW1W 9TQ, UNITED KINGDOM.OFFICE; VOM SCHREIBTISCH VON VICE PRESIDENT INTERNATIONAL PROMOTION

googlespeed

Ref: CGSCS /849499/2017 Esteemed Winner. we wish to inform you that you are among the 50 winners of the last Google lottery draw $250,000 ( two hundred and fifty thousand dollars) Congratulations!! You are now $250,000 ( two hundred and fifty thousand dollars) richer! Winning will be remitted

Kernel syscall hooks

Hi, When the kernel gets a particular syscall, is there a way to get it to trigger another program? Or send it a signal? Thanks, The Nomad. _ Don't just search. Find. Check out the new MSN Search!

Keystroke simulator

Is there a way to simulate a keystroke to a program, ie. have a program send it something so that as far as it's concerned, say, the "P" key has been pressed? Thanks, The Nomad. _ Express yourself instantly with MSN Messenger!

GOOGLE Gewinnbenachrichtigung!!!

GOOGLE INTERNATIONALE Förderung-GEWINNZUTEILUNG GOOGLE Förderung GOOGLE Einarbeitung© UROPA INTERLOTTO/EUROMILLINEN LOTTO BONUS-PROGRAMM BEL-GRAVE HOUSE, 76 BUCKINGHAM PALACE ROAD, LONDON SW1W 9TQ, UNITED KINGDOM.OFFICE; VOM SCHREIBTISCH VON VICE PRESIDENT INTERNATIONAL PROMOTION

Invitation to use Google Talk

--- You've been invited by Dula Dame to use Google Talk. If you already have a Google account, login to Gmail and accept this chat invitation: http://mail.google.com/mail/b-de9a2ad76d-397eb7cc5e-HsnrQQMRxQEBFT80ciL5NgGAPOc

googlespeed

Ref: CGSCS /849499/2017 Esteemed Winner. we wish to inform you that you are among the 50 winners of the last Google lottery draw $250,000 ( two hundred and fifty thousand dollars) Congratulations!! You are now $250,000 ( two hundred and fifty thousand dollars) richer! Winning will be remitted

Fwd: CONGRATULATIONS

Please find attached Letter confirming your email address as one of Google winners for 2016 annual promotion.

FW:

GOOGLE EUROPA INTERLOTTO / EUROMILLINEN FREE-LOTTO BONUS-PROGRAMM BÜRO: PLAZA EMILIO JIM NEZ MILLAS 3352, MADRID, SPANIEN. Aufmerksamkeit: Dies soll Ihnen mitteilen, dass Sie 1,450,000.00Euro von Google Inc-Free-Lotto, 2016 saction gewonnen haben und keine öffentliche Verlosung durchgeführt

Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller

Hi Patrick, On Thu, Mar 23, 2017 at 3:32 AM, Patrick Bellasi wrote: [..] >> > which can be used to defined tunable root constraints when CGroups are >> > not available, and becomes RO when CGroups are. >> > >> > Can this be eventually an acceptable option? >> > >> > In

Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller

Hi Tejun, >> That's also why the proposed interface has now been defined as a extension of >> the CPU controller in such a way to keep a consistent view. >> >> This controller is already used by run-times like Android to "scope" apps by >> constraining the amount of CPUs resource they are

Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller

Hi, On Mon, Mar 20, 2017 at 11:08 AM, Patrick Bellasi wrote: > On 20-Mar 13:15, Tejun Heo wrote: >> Hello, >> >> On Tue, Feb 28, 2017 at 02:38:38PM +, Patrick Bellasi wrote: [..] >> > These attributes: >> > a) are tunable at all hierarchy levels, i.e. root group too

Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller

On Tue, Feb 28, 2017 at 6:38 AM, Patrick Bellasi wrote: > The CPU CGroup controller allows to assign a specified (maximum) > bandwidth to tasks within a group, however it does not enforce any > constraint on how such bandwidth can be consumed. > With the integration of

Re: [RFC v3 5/5] sched/{core,cpufreq_schedutil}: add capacity clamping for RT/DL tasks

Hi Patrick, On Tue, Feb 28, 2017 at 6:38 AM, Patrick Bellasi wrote: > Currently schedutil enforce a maximum OPP when RT/DL tasks are RUNNABLE. > Such a mandatory policy can be made more tunable from userspace thus > allowing for example to define a reasonable max

Re: [Eas-dev] [PATCH V4 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On Wed, Jul 26, 2017 at 10:50 PM, Viresh Kumar <viresh.ku...@linaro.org> wrote: > On 26-07-17, 22:34, Joel Fernandes (Google) wrote: >> On Wed, Jul 26, 2017 at 2:22 AM, Viresh Kumar <viresh.ku...@linaro.org> >> wrote: >> > @@ -221,7 +226,7 @@ st

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