Merge branch 'bpf-add-kmem_cache-iterator-and-kfunc'
authorAlexei Starovoitov <ast@kernel.org>
Tue, 15 Oct 2024 01:13:57 +0000 (18:13 -0700)
committerAlexei Starovoitov <ast@kernel.org>
Wed, 16 Oct 2024 16:21:18 +0000 (09:21 -0700)
commit1477d31b1c9a661a253a644b950f5ce438e4821c
treef13f8b1d43a4c52e13ad58fea028a40574ac88d0
parent989a29cfed9b5092c3e18be14e9032c51bb1c9f6
parenta496d0cdc84d81fbfd2026ef41c8ae9385d01fbb
Merge branch 'bpf-add-kmem_cache-iterator-and-kfunc'

Namhyung Kim says:

====================
bpf: Add kmem_cache iterator and kfunc

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.

v5 changes

 * set PTR_UNTRUSTED for return value of bpf_get_kmem_cache()  (Alexei)
 * add KF_RCU_PROTECTED to bpf_get_kmem_cache().  See below.  (Song)
 * add WARN_ON_ONCE and comment in kmem_cache_iter_seq_next()  (Song)
 * change kmem_cache_iter_seq functions not to call BPF on intermediate stop
 * add a subtest to compare the kmem cache info with /proc/slabinfo  (Alexei)

v4: https://lore.kernel.org/lkml/20241002180956.1781008-1-namhyung@kernel.org

 * skip kmem_cache_destroy() in kmem_cache_iter_seq_stop() if possible  (Vlastimil)
 * fix a bug in the kmem_cache_iter_seq_start() for the last entry

v3: https://lore.kernel.org/lkml/20241002065456.1580143-1-namhyung@kernel.org/

 * rework kmem_cache_iter not to hold slab_mutex when running BPF  (Alexei)
 * add virt_addr_valid() check  (Alexei)
 * fix random test failure by running test with the current task  (Hyeonggon)

v2: https://lore.kernel.org/lkml/20240927184133.968283-1-namhyung@kernel.org/

 * 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 kmem_cache_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_kmem_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-v5' branch in
https://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git

Thanks,
Namhyung
====================

Link: https://lore.kernel.org/r/20241010232505.1339892-1-namhyung@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>