on. Thanks.
Andrii Nakryiko (3):
uprobes: encapsulate preparation of uprobe args buffer
uprobes: prepare uprobe args buffer lazily
uprobes: add speculative lockless system-wide uprobe filter check
kernel/trace/trace_uprobe.c | 103 ++--
1 file changed, 63 inserti
duplicated across uprobe_dispatcher and uretprobe_dispatcher,
and now will be centralized. All this is also in preparation to make
this uprobe_cpu_buffer handling logic optional in the next patch.
Signed-off-by: Andrii Nakryiko
---
kernel/trace/trace_uprobe.c | 75
ger.c
Signed-off-by: Andrii Nakryiko
---
kernel/trace/trace_uprobe.c | 56 ++---
1 file changed, 34 insertions(+), 22 deletions(-)
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index a0f60bb10158..f2875349d124 100644
--- a/kernel/
kernel without any of the changes in this patch set.
As can be seen, we get about 4% - 10% speed up, in total, with both lazy
uprobe buffer and speculative filter check optimizations.
Signed-off-by: Andrii Nakryiko
---
kernel/trace/trace_uprobe.c | 4
1 file changed, 4 insertions(+)
diff --
On Wed, Mar 13, 2024 at 8:16 AM Oleg Nesterov wrote:
>
> LGTM, one nit below.
>
> On 03/12, Andrii Nakryiko wrote:
> >
> > +static struct uprobe_cpu_buffer *prepare_uprobe_buffer(struct trace_uprobe
> > *tu,
> > +
On Wed, Mar 13, 2024 at 8:48 AM Oleg Nesterov wrote:
>
> Again, looks good to me, but I have a minor nit. Feel free to ignore.
>
> On 03/12, Andrii Nakryiko wrote:
> >
> > static void __uprobe_trace_func(struct trace_uprobe *tu,
> >
independent from all this).
>
> On 03/12, Andrii Nakryiko wrote:
> >
> > This patch adds a speculative check before grabbing that rwlock. If
> > nr_systemwide is non-zero, lock is skipped and event is passed through.
> > From examining existing logic it looks correct
On Wed, Mar 13, 2024 at 2:41 AM Jiri Olsa wrote:
>
> On Tue, Mar 12, 2024 at 02:02:30PM -0700, Andrii Nakryiko wrote:
> > This patch set implements two speed ups for uprobe/uretprobe runtime
> > execution
> > path for some common scenarios: BPF-only uprobes (patches #
of tracing tree, hopefully I guessed right;
- simplified user_cpu_buffer usage further (Oleg Nesterov);
- simplified patch #3, just moved speculative check outside of lock (Oleg);
- added Reviewed-by from Jiri Olsa.
Andrii Nakryiko (3):
uprobes: encapsulate preparation of uprobe args buf
duplicated across uprobe_dispatcher and uretprobe_dispatcher,
and now will be centralized. All this is also in preparation to make
this uprobe_cpu_buffer handling logic optional in the next patch.
Reviewed-by: Jiri Olsa
Signed-off-by: Andrii Nakryiko
---
kernel/trace/trace_uprobe.c | 78
ger.c
Reviewed-by: Jiri Olsa
Signed-off-by: Andrii Nakryiko
---
kernel/trace/trace_uprobe.c | 49 +
1 file changed, 28 insertions(+), 21 deletions(-)
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index 9bffaab448a6..b5da95240a31 100644
ilter check optimizations.
[0] https://lore.kernel.org/bpf/20240313131926.ga19...@redhat.com/
Reviewed-by: Jiri Olsa
Signed-off-by: Andrii Nakryiko
---
kernel/trace/trace_uprobe.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/kernel/trace/trace_uprobe.c b/kernel/
On Mon, Mar 18, 2024 at 9:21 PM Masami Hiramatsu wrote:
>
> Hi,
>
> On Mon, 18 Mar 2024 11:17:25 -0700
> Andrii Nakryiko wrote:
>
> > This patch set implements two speed ups for uprobe/uretprobe runtime
> > execution
> > path for some common scenarios: BPF-
, I think we'll want to backport this ASAP to some of
the old kernels we have. Thanks!
Acked-by: Andrii Nakryiko
>
> This change has been tested against production workloads that exhibit
> significant contention on the spinlock and an almost order of magnitude
> reduction for
On Sun, Mar 24, 2024 at 5:07 PM Alexei Starovoitov
wrote:
>
> Hi Andrii,
>
> syzbot found UAF in raw_tp cookie series in bpf-next.
> Reverting the whole merge
> 2e244a72cd48 ("Merge branch 'bpf-raw-tracepoint-support-for-bpf-cookie'")
>
> fixes the issue.
>
> Pls take a look.
> See C reproducer be
On Mon, Mar 25, 2024 at 12:12 PM Jonthan Haslam
wrote:
>
> Hi Ingo,
>
> > > This change has been tested against production workloads that exhibit
> > > significant contention on the spinlock and an almost order of magnitude
> > > reduction for mean uprobe execution time is observed (28 -> 3.5
> >
On Mon, Mar 25, 2024 at 10:27 AM Andrii Nakryiko
wrote:
>
> On Sun, Mar 24, 2024 at 5:07 PM Alexei Starovoitov
> wrote:
> >
> > Hi Andrii,
> >
> > syzbot found UAF in raw_tp cookie series in bpf-next.
> > Reverting the whole merge
> > 2e244a72cd48 (
On Sun, Mar 24, 2024 at 8:03 PM Masami Hiramatsu wrote:
>
> On Thu, 21 Mar 2024 07:57:35 -0700
> Jonathan Haslam wrote:
>
> > Active uprobes are stored in an RB tree and accesses to this tree are
> > dominated by read operations. Currently these accesses are serialized by
> > a spinlock but this
On Wed, Mar 27, 2024 at 5:18 PM Masami Hiramatsu wrote:
>
> On Wed, 27 Mar 2024 17:06:01 +
> Jonthan Haslam wrote:
>
> > > > Masami,
> > > >
> > > > Given the discussion around per-cpu rw semaphore and need for
> > > > (internal) batched attachment API for uprobes, do you think you can
> > >
On Wed, Mar 27, 2024 at 5:45 PM Andrii Nakryiko
wrote:
>
> On Wed, Mar 27, 2024 at 5:18 PM Masami Hiramatsu wrote:
> >
> > On Wed, 27 Mar 2024 17:06:01 +
> > Jonthan Haslam wrote:
> >
> > > > > Masami,
> > > > >
> > &
On Fri, Mar 29, 2024 at 5:36 PM Masami Hiramatsu wrote:
>
> On Fri, 29 Mar 2024 10:33:57 -0700
> Andrii Nakryiko wrote:
>
> > On Wed, Mar 27, 2024 at 5:45 PM Andrii Nakryiko
> > wrote:
> > >
> > > On Wed, Mar 27, 2024 at 5:18 PM Masami Hiramatsu
&
On Wed, Apr 3, 2024 at 7:09 AM Masami Hiramatsu wrote:
>
> On Wed, 3 Apr 2024 11:47:41 +0200
> Jiri Olsa wrote:
>
> > On Wed, Apr 03, 2024 at 10:07:08AM +0900, Masami Hiramatsu wrote:
> > > Hi Jiri,
> > >
> > > On Tue, 2 Apr 2024 11:33:00 +0200
> > > Jiri Olsa wrote:
> > >
> > > > Adding uretpr
On Wed, Apr 3, 2024 at 4:05 AM Jonthan Haslam wrote:
>
> > > > > Given the discussion around per-cpu rw semaphore and need for
> > > > > (internal) batched attachment API for uprobes, do you think you can
> > > > > apply this patch as is for now? We can then gain initial improvements
> > > > > in
On Wed, Apr 3, 2024 at 5:58 PM Masami Hiramatsu wrote:
>
> On Wed, 3 Apr 2024 09:58:12 -0700
> Andrii Nakryiko wrote:
>
> > On Wed, Apr 3, 2024 at 7:09 AM Masami Hiramatsu wrote:
> > >
> > > On Wed, 3 Apr 2024 11:47:41 +0200
> > > Jiri Olsa wrote
On Mon, Apr 15, 2024 at 1:25 AM Jiri Olsa wrote:
>
> On Tue, Apr 02, 2024 at 11:33:00AM +0200, Jiri Olsa wrote:
>
> SNIP
>
> > #include
> > #include
> > @@ -308,6 +309,88 @@ static int uprobe_init_insn(struct arch_uprobe
> > *auprobe, struct insn *insn, bool
> > }
> >
> > #ifdef CONFIG_X86_
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
> converted from ftrace_regs by ftrace_partial_regs(), thus some registers
> may always returns 0. But it should be enou
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 is a kind of performance optimization for fprobe. Since the fprobe
> user does not use these entries, recording t
On Mon, Apr 15, 2024 at 5:49 AM 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;
>
> https://lore.kernel.org/all/170887410337.564249.6360118840946697039.stgit@devnote2/
>
> This versio
4 files changed, 9 insertions(+), 1 deletion(-)
>
LGTM
Acked-by: Andrii Nakryiko
> diff --git a/arch/x86/entry/syscalls/syscall_64.tbl
> b/arch/x86/entry/syscalls/syscall_64.tbl
> index 7e8d46f4147f..af0a33ab06ee 100644
> --- a/arch/x86/entry/syscalls/syscall_64.tbl
> +++ b/arch
ults above.
>
> The uprobe (and uretprobe) kind is determined by which instruction
> is being patched with breakpoint instruction. That's also important
> for uretprobes, because uprobe is installed for each uretprobe.
>
> The performance test is part of bpf selftests:
> tools/
See nits below, but overall LGTM
Acked-by: Andrii Nakryiko
[...]
> @@ -219,6 +301,11 @@ static void test_uretprobe_regs_change(void)
> {
> test__skip();
> }
> +
> +static void test_uretprobe_syscall_call(void)
> +{
> + test__skip();
> +}
>
On Sun, Apr 21, 2024 at 12:43 PM Jiri Olsa wrote:
>
> Adding test that adds return uprobe inside 32 bit task
> and verify the return uprobe and attached bpf programs
> get properly executed.
>
> Signed-off-by: Jiri Olsa
> ---
> tools/testing/selftests/bpf/.gitignore| 1 +
> tools/testin
On Mon, Apr 29, 2024 at 12:33 AM Jiri Olsa wrote:
>
> On Fri, Apr 26, 2024 at 11:03:29AM -0700, Andrii Nakryiko wrote:
> > On Sun, Apr 21, 2024 at 12:43 PM Jiri Olsa wrote:
> > >
> > > Adding test to verify that when called from outside of the
> > > tramp
On Mon, Apr 29, 2024 at 12:39 AM Jiri Olsa wrote:
>
> On Fri, Apr 26, 2024 at 11:06:53AM -0700, Andrii Nakryiko wrote:
> > On Sun, Apr 21, 2024 at 12:43 PM Jiri Olsa wrote:
> > >
> > > Adding test that adds return uprobe inside 32 bit task
> > > and ve
On Mon, Apr 29, 2024 at 6:51 AM Masami Hiramatsu wrote:
>
> Hi Andrii,
>
> On Thu, 25 Apr 2024 13:31:53 -0700
> Andrii Nakryiko wrote:
>
> > Hey Masami,
> >
> > I can't really review most of that code as I'm completely unfamiliar
> > with all
On Sun, Apr 28, 2024 at 4:25 PM Steven Rostedt wrote:
>
> On Thu, 25 Apr 2024 13:31:53 -0700
> Andrii Nakryiko wrote:
>
> I'm just coming back from Japan (work and then a vacation), and
> catching up on my email during the 6 hour layover in Detroit.
>
> > He
On Tue, Apr 30, 2024 at 6:32 AM Masami Hiramatsu wrote:
>
> On Mon, 29 Apr 2024 13:25:04 -0700
> Andrii Nakryiko wrote:
>
> > On Mon, Apr 29, 2024 at 6:51 AM Masami Hiramatsu
> > wrote:
> > >
> > > Hi Andrii,
> > >
> > > On
all(void)
> +{
> + LIBBPF_OPTS(bpf_uprobe_multi_opts, opts,
> + .retprobe = true,
> + );
> + struct uprobe_syscall_executed *skel;
> + int pid, status, err, go[2], c;
> +
> + if (pipe(go))
> + return;
very unlikely to fail, but still, ASSERT_OK() would be in order here
But regardless:
Acked-by: Andrii Nakryiko
[...]
_opts, opts,
> + .retprobe = true,
> + );
> + struct uprobe_syscall_executed *skel;
> + int err, go[2], pid, c, status;
> +
> + if (pipe(go))
> + return;
ASSERT_OK() missing, like in the previous patch
Thanks for switching to pipe() + global variable instead of using trace_pipe.
Acked-by: Andrii Nakryiko
> +
> + skel = uprobe_syscall_executed__open_and_load();
> + if (!ASSERT_OK_PTR(skel, "uprobe_syscall_executed__open_and_load"))
> + goto cleanup;
> +
[...]
On Thu, May 2, 2024 at 5:23 AM Jiri Olsa wrote:
>
> hi,
> as part of the effort on speeding up the uprobes [0] coming with
> return uprobe optimization by using syscall instead of the trap
> on the uretprobe trampoline.
>
> The speed up depends on instruction type that uprobe is installed
> and de
On Thu, May 2, 2024 at 1:04 PM Jiri Olsa wrote:
>
> On Thu, May 02, 2024 at 09:43:02AM -0700, Andrii Nakryiko wrote:
> > On Thu, May 2, 2024 at 5:23 AM Jiri Olsa wrote:
> > >
> > > hi,
> > > as part of the effort on speeding up the uprobes [0] coming w
44
> tools/testing/selftests/bpf/progs/uprobe_syscall_executed.c
>
Acked-by: Andrii Nakryiko
> diff --git a/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c
> b/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c
> index 1a50cd35205d..3ef324c2db50 100644
> --- a/tools/testing/selfte
On Wed, May 1, 2024 at 7:06 PM Masami Hiramatsu wrote:
>
> On Tue, 30 Apr 2024 09:29:40 -0700
> Andrii Nakryiko wrote:
>
> > On Tue, Apr 30, 2024 at 6:32 AM Masami Hiramatsu
> > wrote:
> > >
> > > On Mon, 29 Apr 2024 13:25:04 -0700
> > > A
On Sun, May 5, 2024 at 9:13 AM syzbot
wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:a9e7715ce8b3 libbpf: Avoid casts from pointers to enums in..
> git tree: bpf-next
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=153c1dc498
> kernel config:
On Mon, Oct 2, 2023 at 6:53 AM Artem Savkov wrote:
>
> linux-rt-devel tree contains a patch that adds an extra member to struct
can you please point to the patch itself that makes that change?
> trace_entry. This causes the offset of args field in struct
> trace_event_raw_sys_enter be different
On Thu, Oct 12, 2023 at 6:43 AM Steven Rostedt wrote:
>
> On Thu, 12 Oct 2023 13:45:50 +0200
> Artem Savkov wrote:
>
> > linux-rt-devel tree contains a patch (b1773eac3f29c ("sched: Add support
> > for lazy preemption")) that adds an extra member to struct trace_entry.
> > This causes the offset
On Fri, Oct 13, 2023 at 7:00 AM Steven Rostedt wrote:
>
> On Fri, 13 Oct 2023 08:01:34 +0200
> Artem Savkov wrote:
>
> > > But looking at [0] and briefly reading some of the discussions you,
> > > Steven, had. I'm just wondering if it would be best to avoid
> > > increasing struct trace_entry alt
-
> kernel/trace/trace_kprobe.c | 112
> ++-
> 1 file changed, 68 insertions(+), 44 deletions(-)
>
LGTM.
Acked-by: Andrii Nakryiko
> diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> index e834f149695b..90cf2219adb4 100644
> --- a/kernel/trace/trace_kpro
On Thu, May 23, 2024 at 5:11 AM Jiri Olsa wrote:
>
> hi,
> as part of the effort on speeding up the uprobes [0] coming with
> return uprobe optimization by using syscall instead of the trap
> on the uretprobe trampoline.
>
> The speed up depends on instruction type that uprobe is installed
> and d
On Fri, May 31, 2024 at 10:52 AM Andrii Nakryiko
wrote:
>
> On Thu, May 23, 2024 at 5:11 AM Jiri Olsa wrote:
> >
> > hi,
> > as part of the effort on speeding up the uprobes [0] coming with
> > return uprobe optimization by using syscall instead of the trap
&
On Tue, Jun 4, 2024 at 1:02 PM Jiri Olsa wrote:
>
> Adding new set of callbacks that are triggered on entry and return
> uprobe execution for the attached function.
>
> The session means that those callbacks are 'connected' in a way
> that allows to:
> - control execution of return callback from
On Wed, Jun 5, 2024 at 10:57 AM Oleg Nesterov wrote:
>
> On 06/05, Andrii Nakryiko wrote:
> >
> > so any such
> > limitations will cause problems, issue reports, investigation, etc.
>
> Agreed...
>
> > As one possible solution, what
On Thu, Jun 6, 2024 at 9:46 AM Jiri Olsa wrote:
>
> On Wed, Jun 05, 2024 at 10:50:11PM +0200, Jiri Olsa wrote:
> > On Wed, Jun 05, 2024 at 07:56:19PM +0200, Oleg Nesterov wrote:
> > > On 06/05, Andrii Nakryiko wrote:
> > > >
> > > > so any such
&
On Mon, Jun 10, 2024 at 10:46 PM Masami Hiramatsu wrote:
>
> On Wed, 5 Jun 2024 09:42:45 -0700
> Andrii Nakryiko wrote:
>
> > On Fri, May 31, 2024 at 10:52 AM Andrii Nakryiko
> > wrote:
> > >
> > > On Thu, May 23, 2024 at 5:11 AM Jiri Olsa wrote:
On Tue, Jun 11, 2024 at 3:52 PM Masami Hiramatsu wrote:
>
> On Tue, 11 Jun 2024 13:21:49 +0200
> Jiri Olsa wrote:
>
> > hi,
> > as part of the effort on speeding up the uprobes [0] coming with
> > return uprobe optimization by using syscall instead of the trap
> > on the uretprobe trampoline.
> >
On Mon, Jun 10, 2024 at 4:06 AM Jiri Olsa wrote:
>
> On Thu, Jun 06, 2024 at 09:52:39AM -0700, Andrii Nakryiko wrote:
> > On Thu, Jun 6, 2024 at 9:46 AM Jiri Olsa wrote:
> > >
> > > On Wed, Jun 05, 2024 at 10:50:11PM +0200, Jiri Olsa wrote:
> > > > On W
On Tue, Jun 18, 2024 at 12:43 PM Jiri Olsa wrote:
>
> Nathan reported compilation fail for loongarch arch:
>
> kernel/events/uprobes.c: In function 'arch_uprobe_trampoline':
> arch/loongarch/include/asm/uprobes.h:12:33: error: initializer element is
> not constant
> 12 | #define UPROBE_S
On Thu, Jun 20, 2024 at 12:40 PM Oleg Nesterov wrote:
>
> On 06/20, Andrii Nakryiko wrote:
> >
> > Can we instead ask loongarch folks to rewrite it to be a constant?
> > Having this as a function call is both an inconvenience and potential
> > performance problem (a
robe")
> Reported-by: Nathan Chancellor
> Closes: https://lore.kernel.org/all/20240614174822.GA1185149@thelio-3990X/
> Suggested-by: Andrii Nakryiko
> Signed-off-by: Oleg Nesterov
> ---
> arch/loongarch/include/asm/uprobes.h | 6 --
> arch/loongarch/kernel/upro
On Tue, Jul 2, 2024 at 2:50 AM Peter Zijlstra wrote:
>
>
> +Josj +LKML
>
ack, will add for next revision
> On Mon, Jul 01, 2024 at 04:10:27PM -0700, Andrii Nakryiko wrote:
> > When tracing user functions with uprobe functionality, it's common to
> > install th
that this is the entry to the
function. In that case, return address is still pointed to by %rsp/%esp,
so we fetch it and add to stack trace before proceeding to unwind the
rest using frame pointer-based logic.
Signed-off-by: Andrii Nakryiko
---
v1->v2:
- use native unsigned long for ret_addr
On Tue, Jul 2, 2024 at 4:54 AM Peter Zijlstra wrote:
>
>
> +LKML
>
> On Tue, Jul 02, 2024 at 12:23:53PM +0200, Peter Zijlstra wrote:
> > On Mon, Jul 01, 2024 at 03:39:23PM -0700, Andrii Nakryiko wrote:
> > > This patch set, ultimately, switches global uprobes_tr
On Mon, Jul 1, 2024 at 9:41 AM Jiri Olsa wrote:
>
> Adding support for uprobe consumer to be defined as session and have
> new behaviour for consumer's 'handler' and 'ret_handler' callbacks.
>
> The session means that 'handler' and 'ret_handler' callbacks are
> connected in a way that allows to:
>
On Tue, Jul 2, 2024 at 9:11 AM Jiri Olsa wrote:
>
> On Tue, Jul 02, 2024 at 03:04:08PM +0200, Peter Zijlstra wrote:
> > On Mon, Jul 01, 2024 at 06:41:07PM +0200, Jiri Olsa wrote:
> >
> > > +static void
> > > +uprobe_consumer_account(struct uprobe *uprobe, struct uprobe_consumer
> > > *uc)
> > > +
n
> probe respectively.
>
> Signed-off-by: Jiri Olsa
> ---
> include/uapi/linux/bpf.h | 1 +
> kernel/bpf/syscall.c | 9 +++--
> kernel/trace/bpf_trace.c | 25 +++--
> tools/include/uapi/linux/bpf.h | 1 +
> 4 files ch
> Signed-off-by: Jiri Olsa
> ---
> kernel/trace/bpf_trace.c | 23 +++
> 1 file changed, 15 insertions(+), 8 deletions(-)
>
Acked-by: Andrii Nakryiko
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index 1b19c1cdb5e1..d431b880ca
On Mon, Jul 1, 2024 at 9:42 AM Jiri Olsa wrote:
>
> Adding support to attach program in uprobe session mode
> with bpf_program__attach_uprobe_multi function.
>
> Adding session bool to bpf_uprobe_multi_opts struct that allows
> to load and attach the bpf program via uprobe session.
> the attachmen
On Mon, Jul 1, 2024 at 9:43 AM Jiri Olsa wrote:
>
> Adding uprobe session attach type name to attach_type_name,
> so libbpf_bpf_attach_type_str returns proper string name for
> BPF_TRACE_UPROBE_SESSION attach type.
>
> Signed-off-by: Jiri Olsa
> ---
> tools/lib/bpf/libbpf.c | 1 +
> 1 file chang
++
> .../bpf/progs/uprobe_multi_session.c | 53 +++
> 2 files changed, 95 insertions(+)
> create mode 100644 tools/testing/selftests/bpf/progs/uprobe_multi_session.c
>
LGTM.
Acked-by: Andrii Nakryiko
> diff --git a/tools/testing/selftests/bpf/prog_
> .../bpf/progs/uprobe_multi_session_cookie.c | 48 +++
> 2 files changed, 79 insertions(+)
> create mode 100644
> tools/testing/selftests/bpf/progs/uprobe_multi_session_cookie.c
>
LGTM
Acked-by: Andrii Nakryiko
> diff --git a/tools/testing/selftests/bpf/pr
ti_test.c| 57 +++
> .../progs/uprobe_multi_session_recursive.c| 44 ++
> 2 files changed, 101 insertions(+)
> create mode 100644
> tools/testing/selftests/bpf/progs/uprobe_multi_session_recursive.c
>
Nice!
Acked-by: Andrii Nakryiko
[...]
> +static vo
On Mon, Jul 1, 2024 at 9:44 AM Jiri Olsa wrote:
>
> Adding test that attached/detaches multiple consumers on
> single uprobe and verifies all were hit as expected.
>
> Signed-off-by: Jiri Olsa
> ---
> .../bpf/prog_tests/uprobe_multi_test.c| 203 ++
> .../progs/uprobe_mult
On Tue, Jul 2, 2024 at 4:39 PM Josh Poimboeuf wrote:
>
> On Tue, Jul 02, 2024 at 04:35:56PM -0700, Josh Poimboeuf wrote:
> > On Tue, Jul 02, 2024 at 10:18:58AM -0700, Andrii Nakryiko wrote:
> > > When tracing user functions with uprobe functionality, it's common to
&g
On Tue, Jul 2, 2024 at 4:55 PM Masami Hiramatsu wrote:
>
> Hi Jiri,
>
> On Mon, 1 Jul 2024 18:41:07 +0200
> Jiri Olsa wrote:
>
> > Adding support for uprobe consumer to be defined as session and have
> > new behaviour for consumer's 'handler' and 'ret_handler' callbacks.
> >
> > The session mean
On Tue, Jul 2, 2024 at 6:11 PM Josh Poimboeuf wrote:
>
> On Tue, Jul 02, 2024 at 05:06:14PM -0700, Andrii Nakryiko wrote:
> > > > Should it also check for ENDBR64?
> > > >
> >
> > Sure, I can add a check for endbr64 as well. endbr64 probably can be
&g
tion entry in the stack trace, which is worse
overall.
Signed-off-by: Andrii Nakryiko
---
v2->v3:
- added endr64 detection and extracted heuristics into a function (Josh);
v1->v2:
- use native unsigned long for ret_addr (Peter);
- add same logic for compat logic in perf_callchain_u
On Tue, Jul 2, 2024 at 12:19 PM Peter Zijlstra wrote:
>
> On Tue, Jul 02, 2024 at 10:54:51AM -0700, Andrii Nakryiko wrote:
>
> > > @@ -593,6 +595,12 @@ static struct uprobe *get_uprobe(struct uprobe
> > > *uprobe)
> > > return uprobe;
> > &
On Tue, Jul 2, 2024 at 4:56 PM Paul E. McKenney wrote:
>
> On Tue, Jul 02, 2024 at 09:18:57PM +0200, Peter Zijlstra wrote:
> > On Tue, Jul 02, 2024 at 10:54:51AM -0700, Andrii Nakryiko wrote:
> >
> > > > @@ -593,6 +595,12 @@ static struct uprobe *get_uprobe(
On Wed, Jul 3, 2024 at 1:10 AM Peter Zijlstra wrote:
>
> On Tue, Jul 02, 2024 at 01:51:28PM -0700, Andrii Nakryiko wrote:
> > > +static size_t ri_size(int sessions_cnt)
> > > +{
> > > + struct return_instance *ri __maybe_unused;
> > > +
>
On Tue, Jul 2, 2024 at 11:11 PM Josh Poimboeuf wrote:
>
> On Tue, Jul 02, 2024 at 08:35:08PM -0700, Andrii Nakryiko wrote:
> > On Tue, Jul 2, 2024 at 6:11 PM Josh Poimboeuf wrote:
> > > On Tue, Jul 02, 2024 at 05:06:14PM -0700, Andrii Nakryiko wrote:
> > > > In g
On Wed, Jul 3, 2024 at 1:07 AM Peter Zijlstra wrote:
>
> On Tue, Jul 02, 2024 at 09:47:41PM -0700, Andrii Nakryiko wrote:
>
> > > As you noted, that percpu-rwsem write side is quite insane. And you're
> > > creating this batch complexity to mitigate that.
> >
On Mon, Jul 1, 2024 at 3:39 PM Andrii Nakryiko wrote:
>
> This patch set, ultimately, switches global uprobes_treelock from RW spinlock
> to per-CPU RW semaphore, which has better performance and scales better under
> contention and multiple parallel threads triggering lots of upr
On Wed, Jul 3, 2024 at 8:31 AM Jiri Olsa wrote:
>
> On Tue, Jul 02, 2024 at 01:52:38PM -0700, Andrii Nakryiko wrote:
> > On Tue, Jul 2, 2024 at 9:11 AM Jiri Olsa wrote:
> > >
> > > On Tue, Jul 02, 2024 at 03:04:08PM +0200, Peter Zijlstra wrote:
> > > >
On Wed, Jul 3, 2024 at 9:09 AM Jiri Olsa wrote:
>
> On Tue, Jul 02, 2024 at 05:13:38PM -0700, Andrii Nakryiko wrote:
> > On Tue, Jul 2, 2024 at 4:55 PM Masami Hiramatsu wrote:
> > >
> > > Hi Jiri,
> > >
> > > On Mon, 1 Jul 2024 18:41:07 +0200
>
On Wed, Jul 3, 2024 at 10:13 AM Jiri Olsa wrote:
>
> On Tue, Jul 02, 2024 at 01:51:28PM -0700, Andrii Nakryiko wrote:
>
> SNIP
>
> > > #ifdef CONFIG_UPROBES
> > > @@ -80,6 +83,12 @@ struct uprobe_task {
> > > unsigned int
On Wed, Jul 3, 2024 at 3:41 PM Josh Poimboeuf wrote:
>
> On Wed, Jul 03, 2024 at 01:23:39PM -0700, Andrii Nakryiko wrote:
> > > > [0]
> > > > https://docs.google.com/presentation/d/1k10-HtK7pP5CMMa86dDCdLW55fHOut4co3Zs5akk0t4
> > >
> >
On Wed, Jul 3, 2024 at 3:39 PM Josh Poimboeuf wrote:
>
> On Tue, Jul 02, 2024 at 09:02:03PM -0700, Andrii Nakryiko wrote:
> > @@ -2833,6 +2858,18 @@ perf_callchain_user32(struct pt_regs *regs, struct
> > perf_callchain_entry_ctx *ent
> >
> > fp =
On Thu, Jul 4, 2024 at 8:44 AM Paul E. McKenney wrote:
>
> On Thu, Jul 04, 2024 at 11:15:59AM +0200, Peter Zijlstra wrote:
> > On Wed, Jul 03, 2024 at 02:33:06PM -0700, Andrii Nakryiko wrote:
> >
> > > 2. More tactically, RCU protection seems like the best way forwa
On Thu, Jul 4, 2024 at 2:16 AM Peter Zijlstra wrote:
>
> On Wed, Jul 03, 2024 at 02:33:06PM -0700, Andrii Nakryiko wrote:
>
> > 2. More tactically, RCU protection seems like the best way forward. We
> > got hung up on SRCU vs RCU Tasks Trace. Thanks to Paul, we also
> &g
tion entry in the stack trace, which is worse
overall.
Signed-off-by: Andrii Nakryiko
---
v3->v4:
- use get_user() instead of __get_user(), given untrusted input (Josh);
- reduced #ifdef-ery (Josh);
v2->v3:
- added endr64 detection and extracted heuristics into a function (Josh);
v1-&
On Tue, Jul 9, 2024 at 3:11 AM Peter Zijlstra wrote:
>
> On Mon, Jul 08, 2024 at 04:11:27PM -0700, Andrii Nakryiko wrote:
> > +#ifdef CONFIG_UPROBES
> > +/*
> > + * Heuristic-based check if uprobe is installed at the function entry.
> > + *
> > + * Under as
On Wed, Jul 10, 2024 at 4:39 AM Peter Zijlstra wrote:
>
> On Tue, Jul 09, 2024 at 10:50:00AM -0700, Andrii Nakryiko wrote:
> > On Tue, Jul 9, 2024 at 3:11 AM Peter Zijlstra wrote:
> > >
> > > On Mon, Jul 08, 2024 at 04:11:27PM -0700, Andrii Nakryiko wrote:
uprobes.c | 23 +--
> kernel/trace/bpf_trace.c| 2 +-
> kernel/trace/trace_uprobe.c | 8 ++--
> 4 files changed, 10 insertions(+), 32 deletions(-)
>
LGTM with few nits below.
Acked-by: Andrii Nakryiko
> /*
> * uprobe_apply - unregister an a
On Wed, Jul 10, 2024 at 9:33 AM Oleg Nesterov wrote:
>
> This way uprobe_unregister() and uprobe_apply() do not need find_uprobe() +
> put_uprobe(). And to me this change simplifies the code a bit.
>
> Signed-off-by: Oleg Nesterov
> ---
> include/linux/uprobes.h | 14 ++--
> kernel/e
On Wed, Jul 10, 2024 at 9:49 AM Jiri Olsa wrote:
>
> On Wed, Jul 10, 2024 at 06:31:33PM +0200, Oleg Nesterov wrote:
>
> SNIP
>
> > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> > index 467f358c8ce7..7571811127a2 100644
> > --- a/kernel/trace/bpf_trace.c
> > +++ b/kernel/trace/
On Wed, Jul 10, 2024 at 9:24 AM Josh Poimboeuf wrote:
>
> On Wed, Jul 10, 2024 at 08:11:57AM -0700, Andrii Nakryiko wrote:
> > On Wed, Jul 10, 2024 at 4:39 AM Peter Zijlstra wrote:
> > > On Tue, Jul 09, 2024 at 10:50:00AM -0700, Andrii Nakryiko wrote:
> > > >
tion entry in the stack trace, which is worse
overall.
Signed-off-by: Andrii Nakryiko
---
arch/x86/events/core.c | 63 +
include/linux/uprobes.h | 2 ++
kernel/events/uprobes.c | 2 ++
3 files changed, 67 insertions(+)
diff --git a/arch/x86/event
On Wed, Jul 10, 2024 at 12:38 PM Jiri Olsa wrote:
>
> On Wed, Jul 10, 2024 at 11:23:10AM -0700, Andrii Nakryiko wrote:
> > On Wed, Jul 10, 2024 at 9:49 AM Jiri Olsa wrote:
> > >
> > > On Wed, Jul 10, 2024 at 06:31:33PM +0200, Oleg Nesterov wrote:
> > >
On Wed, Jul 10, 2024 at 1:18 PM Oleg Nesterov wrote:
>
> On 07/10, Andrii Nakryiko wrote:
> >
> > On Wed, Jul 10, 2024 at 9:33 AM Oleg Nesterov wrote:
> > >
> > > This way uprobe_unregister() and uprobe_apply() do not need find_uprobe()
> > >
On Thu, Jul 11, 2024 at 2:28 AM Oleg Nesterov wrote:
>
> On 07/10, Oleg Nesterov wrote:
> >
> > -void uprobe_unregister(struct inode *inode, loff_t offset, struct
> > uprobe_consumer *uc)
> > +void uprobe_unregister(struct uprobe *uprobe, struct uprobe_consumer *uc)
> > {
> > - struct uprobe
1 - 100 of 748 matches
Mail list logo
