mbox series

[RFC/PATCH,bpf-next,0/3] bpf: Add kmem_cache iterator and kfunc (v2)

Message ID 20240927184133.968283-1-namhyung@kernel.org (mailing list archive)
Headers show
Series bpf: Add kmem_cache iterator and kfunc (v2) | expand

Message

Namhyung Kim Sept. 27, 2024, 6:41 p.m. UTC
Hello,

I'm proposing a new iterator and a kfunc for the slab memory allocator
to get information of each kmem_cache like in /proc/slabinfo or
/sys/kernel/slab in more flexible way.

v2 changes)

 * rename it to "kmem_cache_iter"
 * fix a build issue
 * add Acked-by's from Roman and Vlastimil (Thanks!)
 * add error codes in the test for debugging

v1: https://lore.kernel.org/lkml/20240925223023.735947-1-namhyung@kernel.org/
 
My use case is `perf lock contention` tool which shows contended locks
but many of them are not global locks and don't have symbols.  If it
can tranlate the address of the lock in a slab object to the name of
the slab, it'd be much more useful.

I'm not aware of type information in slab yet, but I was told there's
a work to associate BTF ID with it.  It'd be definitely helpful to my
use case.  Probably we need another kfunc to get the start address of
the object or the offset in the object from an address if the type
info is available.  But I want to start with a simple thing first.

The slab_iter iterates kmem_cache objects under slab_mutex and will be
useful for userspace to prepare some work for specific slabs like
setting up filters in advance.  And the bpf_get_slab_cache() kfunc
will return a pointer to a slab from the address of a lock.  And the
test code is to read from the iterator and make sure it finds a slab
cache of the task_struct for the current task.

The code is available at 'bpf/slab-iter-v2' branch in
https://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git

Thanks,
Namhyung


Namhyung Kim (3):
  bpf: Add kmem_cache iterator
  mm/bpf: Add bpf_get_kmem_cache() kfunc
  selftests/bpf: Add a test for kmem_cache_iter

 include/linux/btf_ids.h                       |   1 +
 kernel/bpf/Makefile                           |   1 +
 kernel/bpf/helpers.c                          |   1 +
 kernel/bpf/kmem_cache_iter.c                  | 131 ++++++++++++++++++
 mm/slab_common.c                              |  16 +++
 .../bpf/prog_tests/kmem_cache_iter.c          |  64 +++++++++
 tools/testing/selftests/bpf/progs/bpf_iter.h  |   7 +
 .../selftests/bpf/progs/kmem_cache_iter.c     |  66 +++++++++
 8 files changed, 287 insertions(+)
 create mode 100644 kernel/bpf/kmem_cache_iter.c
 create mode 100644 tools/testing/selftests/bpf/prog_tests/kmem_cache_iter.c
 create mode 100644 tools/testing/selftests/bpf/progs/kmem_cache_iter.c

Comments

Alexei Starovoitov Sept. 29, 2024, 5 p.m. UTC | #1
On Fri, Sep 27, 2024 at 11:41 AM Namhyung Kim <namhyung@kernel.org> wrote:
>
> Hello,
>
> I'm proposing a new iterator and a kfunc for the slab memory allocator
> to get information of each kmem_cache like in /proc/slabinfo or
> /sys/kernel/slab in more flexible way.
>
> v2 changes)

The subject is confusing CI and human readers.
Please use [PATCH v3 bpf-next ..] in the future.

Also note that RFC patches are never going to be applied and they are
ignored by BPF CI.
If you want things to land then drop the RFC tag.
Namhyung Kim Sept. 30, 2024, 1:51 a.m. UTC | #2
Hello Alexei,

On Sun, Sep 29, 2024 at 10:00:56AM -0700, Alexei Starovoitov wrote:
> On Fri, Sep 27, 2024 at 11:41 AM Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > Hello,
> >
> > I'm proposing a new iterator and a kfunc for the slab memory allocator
> > to get information of each kmem_cache like in /proc/slabinfo or
> > /sys/kernel/slab in more flexible way.
> >
> > v2 changes)
> 
> The subject is confusing CI and human readers.
> Please use [PATCH v3 bpf-next ..] in the future.
> 
> Also note that RFC patches are never going to be applied and they are
> ignored by BPF CI.
> If you want things to land then drop the RFC tag.

Ok, I'll change the subject line in the next version.

Thanks,
Namhyung