On Tue, Jul 15, 2025 at 10:21 AM Lorenzo Stoakes
wrote:
>
> On Tue, Jul 15, 2025 at 06:10:16PM +0100, Lorenzo Stoakes wrote:
> > > For PROCMAP_QUERY, we need priv->mm, but the newly added locked_vma
> > > and locked_vma don't need to be persisted between ioctl calls. So we
> > > can just add those
On Tue, Jul 15, 2025 at 3:31 AM Lorenzo Stoakes
wrote:
>
> On Tue, Jul 15, 2025 at 12:23:31PM +0200, Vlastimil Babka wrote:
> > On 7/15/25 11:52, David Hildenbrand wrote:
> > > On 15.07.25 11:40, Lorenzo Stoakes wrote:
> > >> On Tue, Jul 15, 2025 at 10:16:41AM +0200, Vlastimil Babka wrote:
> > >>>
nged, 44 insertions(+), 12 deletions(-)
>
The overall approach in this patch set looks good to me! PROCMAP_QUERY
changes specifically are pretty straightforward, nice. LGTM:
Acked-by: Andrii Nakryiko
And for the rest of the changes you seem to be in good hands, so I'll
just be waiting for th
On Tue, Jun 3, 2025 at 1:37 PM Blake Jones wrote:
>
> When this mode is turned on, "emit_zeroes" and "compact" have no effect,
> and embedded NUL characters always terminate printing of an array.
>
> Signed-off-by: Blake Jones
> ---
> .../selftests/bpf/prog_tests/btf_dump.c | 118 +
On Tue, Jun 3, 2025 at 8:39 AM Blake Jones wrote:
>
> On Tue, Jun 3, 2025 at 6:18 AM Jiri Olsa wrote:
> > > +static int btf_dump_string_data(struct btf_dump *d,
> > > + const struct btf_type *t,
> > > + __u32 id,
> > > +
On Sat, May 31, 2025 at 12:20 AM Blake Jones wrote:
>
> The BTF dumper code currently displays arrays of characters as just that -
> arrays, with each character formatted individually. Sometimes this is what
> makes sense, but it's nice to be able to treat that array as a string.
>
> This change a
On Thu, May 22, 2025 at 6:04 PM Alexei Starovoitov
wrote:
>
> On Wed, May 21, 2025 at 8:00 AM Alan Maguire wrote:
> >
> > > Hi Alan,
> > >
> > > Thanks for taking a look at this. I've been following your related effort
> > > to allow /sys/kernel/btf/vmlinux as a module in support of small systems
On Thu, May 22, 2025 at 4:01 PM Shakeel Butt wrote:
>
> On Tue, May 20, 2025 at 02:01:17PM +0100, Lorenz Bauer wrote:
> > User space needs access to kernel BTF for many modern features of BPF.
> > Right now each process needs to read the BTF blob either in pieces or
> > as a whole. Allow mmaping t
g are not visible to the process.
>
> Signed-off-by: Lorenz Bauer
> ---
> tools/lib/bpf/btf.c | 85
> +++--
> 1 file changed, 69 insertions(+), 16 deletions(-)
>
Almost there, see below. With those changes feel free to add my a
On Wed, May 7, 2025 at 2:14 AM Lorenz Bauer wrote:
>
> On Tue, May 6, 2025 at 10:39 PM Andrii Nakryiko
> wrote:
>
> > > + raw_data = mmap(NULL, end, PROT_READ, MAP_PRIVATE, fd, 0);
> > > + if (!ASSERT_NEQ(raw_data, MAP_FAILED, "mmap_btf"))
On Mon, May 5, 2025 at 11:39 AM Lorenz Bauer wrote:
>
> Add a basic test for the ability to mmap /sys/kernel/btf/vmlinux. Since
> libbpf doesn't have an API to parse BTF from memory we do some basic
> sanity checks ourselves.
>
> Signed-off-by: Lorenz Bauer
> ---
> tools/testing/selftests/bpf/pr
On Mon, May 5, 2025 at 11:39 AM Lorenz Bauer wrote:
>
> User space needs access to kernel BTF for many modern features of BPF.
> Right now each process needs to read the BTF blob either in pieces or
> as a whole. Allow mmaping the sysfs file so that processes can directly
> access the memory alloc
On Mon, May 5, 2025 at 11:39 AM Lorenz Bauer wrote:
>
> Teach libbpf to use mmap when parsing vmlinux BTF from /sys. We don't
> apply this to fall-back paths on the regular file system because there
> is no way to ensure that modifications underlying the MAP_PRIVATE
> mapping are not visible to th
On Tue, Apr 29, 2025 at 10:25 AM Jann Horn wrote:
>
> On Tue, Apr 29, 2025 at 7:15 PM Suren Baghdasaryan wrote:
> > On Tue, Apr 29, 2025 at 8:56 AM Jann Horn wrote:
> > > On Wed, Apr 23, 2025 at 12:54 AM Andrii Nakryiko
> > > wrote:
> > > > On Fri, A
On Thu, Apr 24, 2025 at 9:42 AM Liam R. Howlett wrote:
>
> * Andrii Nakryiko [250424 12:04]:
> > On Thu, Apr 24, 2025 at 8:20 AM Suren Baghdasaryan
> > wrote:
> > >
> > > On Wed, Apr 23, 2025 at 5:24 PM Liam R. Howlett
> > > wrote:
>
On Thu, Apr 24, 2025 at 8:20 AM Suren Baghdasaryan wrote:
>
> On Wed, Apr 23, 2025 at 5:24 PM Liam R. Howlett
> wrote:
> >
> > * Andrii Nakryiko [250423 18:06]:
> > > On Wed, Apr 23, 2025 at 2:49 PM Suren Baghdasaryan
> > > wrote:
> > >
On Wed, Apr 23, 2025 at 2:49 PM Suren Baghdasaryan wrote:
>
> On Tue, Apr 22, 2025 at 3:49 PM Andrii Nakryiko
> wrote:
> >
> > On Fri, Apr 18, 2025 at 10:50 AM Suren Baghdasaryan
> > wrote:
> > >
> > > With maple_tree supporting vma tree traver
On Wed, Apr 23, 2025 at 5:14 AM KaFai Wan wrote:
>
> Adding support to access arguments with const void pointer arguments
> in tracing programs.
>
> Currently we allow tracing programs to access void pointers. If we try to
> access argument which is pointer to const void like 2nd argument in kfree
On Thu, Apr 17, 2025 at 12:14 AM Alexis Lothoré
wrote:
>
> Hi Andrii,
>
> On Wed Apr 16, 2025 at 11:24 PM CEST, Andrii Nakryiko wrote:
> > On Fri, Apr 11, 2025 at 1:32 PM Alexis Lothoré (eBPF Foundation)
> > wrote:
> >>
> >> In order to properly JIT the
On Fri, Apr 18, 2025 at 10:50 AM Suren Baghdasaryan wrote:
>
> Utilize speculative vma lookup to find and snapshot a vma without
> taking mmap_lock during PROCMAP_QUERY ioctl execution. Concurrent
> address space modifications are detected and the lookup is retried.
> While we take the mmap_lock f
On Fri, Apr 18, 2025 at 10:50 AM Suren Baghdasaryan wrote:
>
> With maple_tree supporting vma tree traversal under RCU and vma and
> its important members being RCU-safe, /proc/pid/maps can be read under
> RCU and without the need to read-lock mmap_lock. However vma content
> can change from under
On Fri, Apr 11, 2025 at 1:32 PM Alexis Lothoré (eBPF Foundation)
wrote:
>
> In order to properly JIT the trampolines needed to attach BPF programs
> to functions, some architectures like ARM64 need to know about the
> alignment needed for the function arguments. Such alignment can
> generally be d
On Tue, Apr 8, 2025 at 11:33 AM Malaya Kumar Rout
wrote:
>
> Static Analyis for bench_htab_mem.c with cppcheck:error
typo: analysis (lower case and typo)
you can also make into a bit more human-readable sentence:
"Static analysis found an issue in bench_htab_mem.c:
> tools/testing/selftests/b
On Sun, Mar 23, 2025 at 11:43 PM Malaya Kumar Rout
wrote:
>
> Static Analyis for bench_htab_mem.c with cppcheck:error
> tools/testing/selftests/bpf/benchs/bench_htab_mem.c:284:3:
> error: Resource leak: fd [resourceLeak]
> tools/testing/selftests/bpf/prog_tests/sk_assign.c:41:3:
> error: Resource
On Wed, Feb 12, 2025 at 2:31 PM Martin Kelly
wrote:
>
> On Mon, 2025-02-10 at 16:06 -0800, Andrii Nakryiko wrote:
> > > Tracking associated maps for a program is not necessary. As long as
> > > the last BPF program using the BPF map is unloaded, the kernel will
>
On Fri, Feb 7, 2025 at 5:13 PM Martin Kelly
wrote:
>
> On Wed, 2025-02-05 at 14:33 -0800, Andrii Nakryiko wrote:
> > > > >
> > > > > I see two ways forward for you. Either you can break apart your
> > > > > BPF
> > > >
On Thu, Jan 30, 2025 at 2:34 PM Daniel Xu wrote:
>
> Since 67ab80a01886 ("selftests/bpf: Prefer static linking for LLVM
> libraries"), only statically linking test_progs is supported. However,
> some distros only provide a dynamically linkable LLVM.
>
> This commit adds a fallback for dynamically
On Tue, Jan 28, 2025 at 3:08 PM Martin Kelly
wrote:
>
> On Fri, 2025-01-24 at 10:31 -0800, Andrii Nakryiko wrote:
> > > On Wed, Jan 22, 2025 at 1:53 PM Slava Imameev
> > > wrote:
> > > > >
> > > > > BPF programs designated as dynamically loa
On Wed, Jan 22, 2025 at 1:53 PM Slava Imameev
wrote:
>
> BPF programs designated as dynamically loaded can be loaded and
> attached independently after the initial bpf_object loading and
> attaching.
>
> These programs can also be reloaded and reattached multiple times,
> enabling more flexible ma
On Wed, Jan 15, 2025 at 6:16 AM Saket Kumar Bhaskar wrote:
>
> On Tue, Jan 14, 2025 at 02:40:20PM -0800, Andrii Nakryiko wrote:
> > On Sat, Jan 11, 2025 at 11:53 AM Saket Kumar Bhaskar
> > wrote:
> > >
> > > CCing Maddy and MPE
> > > On Fri, Jan
On Thu, Jan 16, 2025 at 2:54 PM Paul E. McKenney wrote:
>
> On Thu, Jan 16, 2025 at 01:52:53PM -0800, Andrii Nakryiko wrote:
> > On Thu, Jan 16, 2025 at 12:21 PM Paul E. McKenney
> > wrote:
> > >
> > > This commit adds srcu_read_{,un}lock_fast(), whic
pointer and
> that from srcu_read_lock_lite() is only a 32-bit int.
>
> [ paulmck: Apply feedback from Akira Yokosawa. ]
>
> Signed-off-by: Paul E. McKenney
> Cc: Alexei Starovoitov
> Cc: Andrii Nakryiko
> Cc: Peter Zijlstra
> Cc: Kent Overstreet
> Cc:
> ---
> i
On Sat, Jan 11, 2025 at 11:53 AM Saket Kumar Bhaskar
wrote:
>
> CCing Maddy and MPE
> On Fri, Jan 10, 2025 at 02:29:42PM -0800, Andrii Nakryiko wrote:
> > On Fri, Jan 10, 2025 at 2:49 AM Saket Kumar Bhaskar
> > wrote:
> > >
> > > On Thu, Nov 21, 2024 at
On Mon, Dec 23, 2024 at 12:33 AM Li Zhijian wrote:
>
> Fixes an issue where out-of-tree kselftest builds fail when building
> the BPF and bpftools components. The failure occurs because the top-level
> Makefile passes a relative srctree path to its sub-Makefiles, which
> leads to errors in locatin
On Thu, Jan 9, 2025 at 3:42 PM Daniel Xu wrote:
>
> `-l2 -v` is a useful combination of flags to dump the entire
> verification log. This is helpful when making changes to the verifier,
> as you can see what it thinks program one instruction at a time.
>
> This was more or less a hidden feature be
On Fri, Jan 10, 2025 at 2:49 AM Saket Kumar Bhaskar wrote:
>
> On Thu, Nov 21, 2024 at 04:00:13PM -0800, Andrii Nakryiko wrote:
> > On Wed, Nov 20, 2024 at 6:52 AM Saket Kumar Bhaskar
> > wrote:
> > >
> > > On Fri, Nov 08, 2024 at 10:43:54AM -0800, Andrii N
On Fri, Dec 13, 2024 at 7:13 PM Eduard Zingerman wrote:
>
> On Fri, 2024-12-13 at 19:44 -0700, Daniel Xu wrote:
>
> [...]
>
> > > > + /* First handle precisely tracked STACK_ZERO, up to
> > > > BPF_REG_SIZE */
> > > > + stype = state->stack[spi].slot_type;
> > > > + for (i = 0;
On Thu, Dec 12, 2024 at 3:23 PM Daniel Xu wrote:
>
> This commit allows progs to elide a null check on statically known map
> lookup keys. In other words, if the verifier can statically prove that
> the lookup will be in-bounds, allow the prog to drop the null check.
>
> This is useful for two rea
On Thu, Dec 5, 2024 at 9:35 AM Thomas Weißschuh wrote:
>
> The generic function from the sysfs core can replace the custom one.
>
> Signed-off-by: Thomas Weißschuh
> ---
> kernel/bpf/btf.c | 15 ++-
> 1 file changed, 2 insertions(+), 13 deletions(-)
>
[0]
> https://lore.kernel.org/lkml/20241122-sysfs-const-bin_attr-bpf-v1-1-823aea399...@weissschuh.net/
> ---
> kernel/bpf/sysfs_btf.c | 12 ++--
> 1 file changed, 2 insertions(+), 10 deletions(-)
>
Acked-by: Andrii Nakryiko
> diff --git a/kernel/
On Wed, Nov 20, 2024 at 6:52 AM Saket Kumar Bhaskar wrote:
>
> On Fri, Nov 08, 2024 at 10:43:54AM -0800, Andrii Nakryiko wrote:
> > On Sun, Nov 3, 2024 at 9:00 PM Saket Kumar Bhaskar
> > wrote:
> > >
> > > Since commit 94746890202cf ("powerpc: Don'
On Mon, Nov 11, 2024 at 7:17 AM Paul E. McKenney wrote:
>
> On Mon, Nov 11, 2024 at 04:47:49PM +0530, Neeraj Upadhyay wrote:
> >
> > > +/**
> > > + * srcu_read_unlock_lite - unregister a old reader from an
> > > SRCU-protected structure.
> > > + * @ssp: srcu_struct in which to unregister the old
On Sun, Nov 3, 2024 at 9:00 PM Saket Kumar Bhaskar wrote:
>
> Since commit 94746890202cf ("powerpc: Don't add __powerpc_ prefix to
> syscall entry points") drops _powerpc prefix to syscall entry points,
> even though powerpc now supports syscall wrapper, so /proc/kallsyms
> have symbols for syscal
On Mon, Nov 4, 2024 at 2:26 AM Björn Töpel wrote:
>
> patchwork-bot+netdev...@kernel.org writes:
>
> > Hello:
> >
> > This series was applied to bpf/bpf-next.git (master)
> > by Andrii Nakryiko :
> >
> > On Fri, 27 Sep 2024 15:13:52 +0200 you wrote:
On Wed, Oct 23, 2024 at 9:46 AM Alan Huang wrote:
>
> On Oct 24, 2024, at 00:34, Andrii Nakryiko wrote:
> >
> > On Tue, Oct 22, 2024 at 11:40 PM Christoph Hellwig
> > wrote:
> >>
> >> On Tue, Oct 22, 2024 at 10:29:13AM -0700, Andrii Nak
On Tue, Oct 22, 2024 at 11:40 PM Christoph Hellwig wrote:
>
> On Tue, Oct 22, 2024 at 10:29:13AM -0700, Andrii Nakryiko wrote:
> > >
> > > Would this work?
> > >
> > > #define SRCU_INVALID_INDEX -1
> > >
> >
> > But why?
>
&g
On Tue, Oct 22, 2024 at 7:26 AM Paul E. McKenney wrote:
>
> On Tue, Oct 22, 2024 at 12:13:12AM -0700, Christoph Hellwig wrote:
> > On Tue, Oct 22, 2024 at 09:10:18AM +0200, Peter Zijlstra wrote:
> > > Ah, well, the thing that got us here is that we (Andrii and me) wanted
> > > to use -1 as an 'inv
On Mon, Oct 21, 2024 at 8:30 PM Paul E. McKenney wrote:
>
> On Mon, Oct 21, 2024 at 07:01:02PM -0700, Andrii Nakryiko wrote:
> > On Mon, Oct 21, 2024 at 5:21 PM Paul E. McKenney wrote:
> > >
> > > On Mon, Oct 21, 2024 at 04:50:44PM -0700, Andrii Nakryiko wrote:
>
On Mon, Oct 21, 2024 at 5:21 PM Paul E. McKenney wrote:
>
> On Mon, Oct 21, 2024 at 04:50:44PM -0700, Andrii Nakryiko wrote:
> > On Mon, Oct 21, 2024 at 3:13 PM Paul E. McKenney wrote:
> > >
> > > For almost 20 years, the int return value from srcu_read_lock() has
t; Cc: Peter Zijlstra
> Cc: Andrii Nakryiko
> diff --git a/include/linux/srcu.h b/include/linux/srcu.h
> index bab1dae3f69e6..512a8c54ba5ba 100644
> --- a/include/linux/srcu.h
> +++ b/include/linux/srcu.h
> @@ -238,13 +238,14 @@ void srcu_check_read_flavor(struct srcu_struct *ssp,
On Fri, Oct 11, 2024 at 10:39 AM Paul E. McKenney wrote:
>
> Where RCU is watching is where it is OK to invoke rcu_read_lock().
>
> Reported-by: Andrii Nakryiko
> Signed-off-by: Paul E. McKenney
> ---
> include/linux/srcu.h | 3 ++-
> 1 file changed, 2 insertions(+), 1
On Wed, Oct 9, 2024 at 11:46 PM Zhu Jun wrote:
>
> The error check is no longer needed for this test case,
> simplifying the code.
>
> Signed-off-by: Zhu Jun
> ---
> tools/testing/selftests/bpf/prog_tests/signal_pending.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
please add b...
On Mon, Oct 7, 2024 at 11:29 AM Tyrone Wu wrote:
>
> From: tyrone-wu
>
> Previously when retrieving `bpf_link_info.perf_event` for
> kprobe/uprobe/tracepoint, the `name_len` field was not populated by the
> kernel, leaving it to reflect the value initially set by the user. This
> behavior was inc
On Tue, Sep 3, 2024 at 3:08 PM Andrii Nakryiko
wrote:
>
> On Tue, Sep 3, 2024 at 9:32 AM Paul E. McKenney wrote:
> >
> > Hello!
> >
> > This series provides light-weight readers for SRCU. This lightness
> > is selected by the caller by usi
On Fri, Sep 27, 2024 at 1:23 AM Jiapeng Chong
wrote:
>
> Use of macro ARRAY_SIZE to calculate array size minimizes
> the redundant code and improves code reusability.
>
> ./tools/testing/selftests/bpf/prog_tests/core_reloc_raw.c:98:34-35: WARNING:
> Use ARRAY_SIZE.
> ./tools/testing/selftests/bpf
On Fri, Sep 27, 2024 at 6:14 AM Björn Töpel wrote:
>
> From: Björn Töpel
>
> The prog_tests programs do not include the per-arch tools include
> path, e.g. tools/arch/riscv/include. Some architectures depend those
> files to build properly.
>
> Include tools/arch/$(SUBARCH)/include in the selftes
On Fri, Sep 27, 2024 at 6:14 AM Björn Töpel wrote:
>
> From: Björn Töpel
>
> libbpf does not include the per-arch tools include path, e.g.
> tools/arch/riscv/include. Some architectures depend those files to
> build properly.
>
> Include tools/arch/$(SUBARCH)/include in the libbpf build.
>
> Fixe
On Tue, Sep 10, 2024 at 8:31 PM Daniel Xu wrote:
>
> On Tue, Sep 10, 2024 at 05:39:55PM GMT, Andrii Nakryiko wrote:
> > On Tue, Sep 10, 2024 at 4:44 PM Daniel Xu wrote:
> > >
> > > On Tue, Sep 10, 2024 at 03:21:04PM GMT, Andrii Nakryiko wrote:
> > > >
On Tue, Sep 10, 2024 at 4:44 PM Daniel Xu wrote:
>
> On Tue, Sep 10, 2024 at 03:21:04PM GMT, Andrii Nakryiko wrote:
> > On Tue, Sep 10, 2024 at 3:16 PM Daniel Xu wrote:
> > >
> > >
> > >
> > > On Tue, Sep 10, 2024, at 2:07 PM, Daniel Xu wrote
On Tue, Sep 10, 2024 at 3:16 PM Daniel Xu wrote:
>
>
>
> On Tue, Sep 10, 2024, at 2:07 PM, Daniel Xu wrote:
> > On Tue, Sep 10, 2024 at 01:41:41PM GMT, Andrii Nakryiko wrote:
> >> On Tue, Sep 10, 2024 at 11:36 AM Alexei Starovoitov
> [...]
> >
> >>
>
On Tue, Sep 10, 2024 at 2:07 PM Daniel Xu wrote:
>
> On Tue, Sep 10, 2024 at 01:41:41PM GMT, Andrii Nakryiko wrote:
> > On Tue, Sep 10, 2024 at 11:36 AM Alexei Starovoitov
> > wrote:
> > >
> > > On Mon, Sep 9, 2024 at 5:55 PM Daniel Xu wrote:
> > >
On Tue, Sep 10, 2024 at 11:36 AM Alexei Starovoitov
wrote:
>
> On Mon, Sep 9, 2024 at 5:55 PM Daniel Xu wrote:
> >
> > Right now there exists prog produce / userspace consume and userspace
> > produce / prog consume support. But it is also useful to have prog
> > produce / prog consume.
> >
> > F
On Wed, Aug 28, 2024 at 5:17 AM Lin Yikai wrote:
>
> These two patch enable the use of "vmtest.sh" for cross-compile arm64 on
> x86_64 host.
> This is essential for utilizing BPF on Android (arm64),
> as the compilation server is running on Ubuntu (x86).
>
> Following previous guidance from V1, t
On Tue, Sep 3, 2024 at 9:32 AM Paul E. McKenney wrote:
>
> Hello!
>
> This series provides light-weight readers for SRCU. This lightness
> is selected by the caller by using the new srcu_read_lock_lite() and
> srcu_read_unlock_lite() flavors instead of the usual srcu_read_lock() and
> srcu_read_u
On Thu, Aug 29, 2024 at 12:45 PM Jiri Olsa wrote:
>
> The idea is to create and monitor 3 uprobes, each trigered in separate
typo: triggered
> process and make sure the bpf program gets executed just for the proper
> PID specified via pid filter.
>
> Signed-off-by: Jiri Olsa
> ---
> .../bpf/pr
On Fri, Aug 30, 2024 at 1:21 PM Oleg Nesterov wrote:
>
> On 08/30, Andrii Nakryiko wrote:
> >
>
> Andrii, let me reply to your email "out of order". First of all:
>
> > Can we please let me land these patches first? It's been a while. I
> > don&
gt;
> url:
> https://github.com/intel-lab-lkp/linux/commits/Andrii-Nakryiko/uprobes-revamp-uprobe-refcounting-and-lifetime-management/20240830-024135
> base: tip/perf/core
> patch link:
> https://lore.kernel.org/r/20240829183741.3331213-9-andrii%40kernel.org
> patch su
On Fri, Aug 30, 2024 at 7:33 AM Oleg Nesterov wrote:
>
> On 08/30, Jiri Olsa wrote:
> >
> > with this change the probe will not get removed in the attached test,
> > it'll get 2 hits, without this change just 1 hit
>
> I don't understand the code in tools/...bpf../ at all, can't comment,
>
> > but
On Thu, Aug 29, 2024 at 4:10 PM Jiri Olsa wrote:
>
> On Thu, Aug 29, 2024 at 11:37:37AM -0700, Andrii Nakryiko wrote:
> > uprobe->register_rwsem is one of a few big bottlenecks to scalability of
> > uprobes, so we need to get rid of it to improve uprobe performance and
>
On Tue, Aug 27, 2024 at 4:34 AM Liao, Chang wrote:
>
> Hi, Mark
>
> Would you like to discuss this patch further, or do you still believe
> emulating
> STP to push FP/LR into the stack in kernel is not a good idea?
>
Please send an updated version of your patches taking into account
various smal
do 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.
Signed-off-by: Andrii Nakryiko
---
kernel/events/uprobes.c | 37 +++--
1
:3.723 ± 0.002M/s ( 0.058M/s/cpu)
Peak througput increased from 3.7 mln/s (uprobe triggerings) up to about
8 mln/s. For uretprobes it's a bit more modest with bump from 2.4 mln/s
to 5mln/s.
Suggested-by: Peter Zijlstra (Intel)
Signed-off-by: Andrii Nakryiko
---
kernel/events
From: Peter Zijlstra
Much like latch_tree, add two RCU methods for the regular RB-tree,
which can be used in conjunction with a seqcount to provide lockless
lookups.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Masami Hiramatsu (Google)
---
include/linux/rbtree.h | 67 ++
r Zijlstra (Intel)
Co-developed-by: Andrii Nakryiko
Signed-off-by: Andrii Nakryiko
---
include/linux/uprobes.h | 8 +--
kernel/events/uprobes.c | 21 +--
kernel/trace/bpf_trace.c | 5 -
kernel/trace/trac
s extra
lock won't hurt performance, overall, but we also avoid the need for any
extra protection (e.g., seqcount locks).
Signed-off-by: Andrii Nakryiko
---
include/linux/uprobes.h | 2 +-
kernel/events/uprobes.c | 104 +++-
2 files changed, 62 insertions(+), 4
It serves no purpose beyond adding unnecessray argument passed to the
filter callback. Just get rid of it, no one is actually using it.
Signed-off-by: Andrii Nakryiko
---
include/linux/uprobes.h | 10 +-
kernel/events/uprobes.c | 18 +++---
kernel/trace/bpf_trace.c
ollow up patches
by making them use SRCU with timeout.
Signed-off-by: Andrii Nakryiko
---
kernel/events/uprobes.c | 94 +++--
1 file changed, 54 insertions(+), 40 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 147561c
orking together:
__insert_uprobe() will remove uprobe from RB-tree, if it can't bump
refcount and will retry to insert the new uprobe instance. put_uprobe()
won't attempt to remove uprobe from RB-tree, if it's already not there.
All that is protected by uprobes_treelock, which
->v3:
- undid rcu and rb_node fields colocation which were causing crashes (Oleg);
- ensure synchronize_srcu() on registration failure in patch #4 (Oleg);
v1->v2:
- added back missed kfree() in patch #1 (Oleg);
- forgot the rest, but there were a few small things here and there.
Andrii N
On Tue, Aug 27, 2024 at 8:55 PM Masami Hiramatsu wrote:
>
> On Tue, 13 Aug 2024 13:34:09 -0700
> Andrii Nakryiko wrote:
>
> > trace_uprobe->nhit counter is not incremented atomically, so its value
> > is questionable in when uprobe is hit on multiple CPUs simultaneousl
On Sun, Aug 25, 2024 at 3:15 AM Masami Hiramatsu wrote:
>
> On Tue, 13 Aug 2024 17:41:04 +0200
> Oleg Nesterov wrote:
>
> > On 08/13, Masami Hiramatsu wrote:
> > >
> > > > @@ -62,7 +63,7 @@ struct trace_uprobe {
> > > > struct uprobe *uprobe;
> > >
> > > BTW, what is this chan
On Thu, Aug 22, 2024 at 10:35 AM Jiri Olsa wrote:
>
> On Thu, Aug 22, 2024 at 09:59:29AM -0700, Andrii Nakryiko wrote:
> > On Thu, Aug 22, 2024 at 7:22 AM Jiri Olsa wrote:
> > >
> > > On Mon, Aug 12, 2024 at 09:29:08PM -0700, Andrii Nakryiko wrote:
> > &g
On Thu, Aug 22, 2024 at 7:22 AM Jiri Olsa wrote:
>
> On Mon, Aug 12, 2024 at 09:29:08PM -0700, Andrii Nakryiko wrote:
>
> SNIP
>
> > @@ -1125,18 +1103,31 @@ void uprobe_unregister(struct uprobe *uprobe,
> > struct uprobe_consumer *uc)
> > int err;
On Thu, Aug 15, 2024 at 9:49 AM Andrii Nakryiko
wrote:
>
> On Thu, Aug 15, 2024 at 6:25 AM Oleg Nesterov wrote:
> >
> > On 08/12, Andrii Nakryiko wrote:
> > >
> > > ( In addition to previously posted first 8 patches, I'm sending 5 more as
> > >
On Tue, Aug 13, 2024 at 1:34 PM Andrii Nakryiko wrote:
>
> trace_uprobe->nhit counter is not incremented atomically, so its value
> is questionable in when uprobe is hit on multiple CPUs simultaneously.
>
> Also, doing this shared counter increment across many CPUs causes
On Tue, Aug 20, 2024 at 8:06 AM Oleg Nesterov wrote:
>
> On 08/19, Andrii Nakryiko wrote:
> >
> > On Mon, Aug 19, 2024 at 6:41 AM Oleg Nesterov wrote:
> > >
> > > On 08/12, Andrii Nakryiko wrote:
> > > >
> > > > Avoid ta
On Mon, Aug 19, 2024 at 6:41 AM Oleg Nesterov wrote:
>
> On 08/12, Andrii Nakryiko wrote:
> >
> > Avoid taking refcount on uprobe in prepare_uretprobe(), instead take
> > uretprobe-specific SRCU lock and keep it active as kernel transfers
> > control back to user s
On Tue, Aug 13, 2024 at 6:28 AM Matteo Croce wrote:
>
> From: Matteo Croce
>
> The helper bpf_current_task_under_cgroup() currently is only allowed for
> tracing programs, allow its usage also in the BPF_CGROUP_* program types.
>
> Move the code from kernel/trace/bpf_trace.c to kernel/bpf/helpers
On Tue, Aug 13, 2024 at 6:28 AM Matteo Croce wrote:
>
> From: Matteo Croce
>
> These kfuncs are enabled even in BPF_PROG_TYPE_TRACING, so they
> should be safe also in BPF_CGROUP_* programs.
>
> In enum btf_kfunc_hook, rename BTF_KFUNC_HOOK_CGROUP_SKB to a more
> generic BTF_KFUNC_HOOK_CGROUP, si
On Thu, Aug 15, 2024 at 11:58 AM Jann Horn wrote:
>
> +brauner for "struct file" lifetime
>
> On Thu, Aug 15, 2024 at 7:45 PM Suren Baghdasaryan wrote:
> > On Thu, Aug 15, 2024 at 9:47 AM Andrii Nakryiko
> > wrote:
> > >
> > >
On Thu, Aug 15, 2024 at 2:58 AM Mark Rutland wrote:
>
> On Wed, Aug 14, 2024 at 08:03:56AM +, Liao Chang wrote:
> > As Andrii pointed out, the uprobe/uretprobe selftest bench run into a
> > counterintuitive result that nop and push variants are much slower than
> > ret variant [0]. The root ca
On Thu, Aug 15, 2024 at 12:59 AM Liao, Chang wrote:
>
>
>
> 在 2024/8/15 0:57, Andrii Nakryiko 写道:
> > On Tue, Aug 13, 2024 at 9:17 PM Liao, Chang wrote:
> >>
> >>
> >>
> >> 在 2024/8/13 1:49, Andrii Nakryiko 写道:
&g
On Wed, Aug 14, 2024 at 7:58 PM Liao, Chang wrote:
>
>
>
> 在 2024/8/15 2:42, Andrii Nakryiko 写道:
> > On Tue, Aug 13, 2024 at 9:17 PM Liao, Chang wrote:
> >>
> >>
> >>
> >> 在 2024/8/13 1:49, Andrii Nakryiko 写道:
&g
On Thu, Aug 15, 2024 at 6:25 AM Oleg Nesterov wrote:
>
> On 08/12, Andrii Nakryiko wrote:
> >
> > ( In addition to previously posted first 8 patches, I'm sending 5 more as an
> > RFC for people to get the general gist of where this work heading and what
> > upro
On Thu, Aug 15, 2024 at 6:44 AM Mateusz Guzik wrote:
>
> On Tue, Aug 13, 2024 at 08:36:03AM -0700, Suren Baghdasaryan wrote:
> > On Mon, Aug 12, 2024 at 11:18 PM Mateusz Guzik wrote:
> > >
> > > On Mon, Aug 12, 2024 at 09:29:17PM -0700, Andrii Nakryiko wrote:
&g
On Tue, Aug 13, 2024 at 9:17 PM Liao, Chang wrote:
>
>
>
> 在 2024/8/13 1:49, Andrii Nakryiko 写道:
> > On Mon, Aug 12, 2024 at 4:11 AM Liao, Chang wrote:
> >>
> >>
> >>
> >> 在 2024/8/9 2:26, Andrii Nakryiko 写道:
> >>> On Thu, Aug
On Tue, Aug 13, 2024 at 9:17 PM Liao, Chang wrote:
>
>
>
> 在 2024/8/13 1:49, Andrii Nakryiko 写道:
> > On Mon, Aug 12, 2024 at 4:11 AM Liao, Chang wrote:
> >>
> >>
> >>
> >> 在 2024/8/9 2:26, Andrii Nakryiko 写道:
> >>> On Thu, Aug
of CPUs.
Solve both problems by making this a per-CPU counter.
Reviewed-by: Oleg Nesterov
Signed-off-by: Andrii Nakryiko
---
kernel/trace/trace_uprobe.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/kernel/trace/trace_uprobe.c b/kernel/tr
On Tue, Aug 13, 2024 at 7:49 AM Suren Baghdasaryan wrote:
>
> On Mon, Aug 12, 2024 at 11:07 PM Mateusz Guzik wrote:
> >
> > On Mon, Aug 12, 2024 at 09:29:16PM -0700, Andrii Nakryiko wrote:
> > > Add RCU protection for file struct's backing memory by adding
&g
On Tue, Aug 13, 2024 at 7:50 AM Oleg Nesterov wrote:
>
> On 08/09, Andrii Nakryiko wrote:
> >
> > @@ -815,13 +824,21 @@ static int probes_profile_seq_show(struct seq_file
> > *m, void *v)
> > {
> > struct dyn_event *ev = v;
> > struct trace
1 - 100 of 790 matches
Mail list logo
