[bpf-next,0/4] bpf/crib: Add open-coded style process file iterator and file related CRIB kfuncs

Message

Juntong Deng Oct. 29, 2024, 10:34 p.m. UTC

This patch series adds open-coded style process file iterator
bpf_iter_task_file and file related kfuncs bpf_fget_task(),
bpf_get_file_ops_type(), and corresponding selftests test cases.

Known future merge conflict: In linux-next task_lookup_next_fdget_rcu()
has been removed and replaced with fget_task_next() [0], but that has
not happened yet in bpf-next, so I still
use task_lookup_next_fdget_rcu() in bpf_iter_task_file_next().

[0]: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=8fd3395ec9051a52828fcca2328cb50a69dea8ef

Although iter/task_file already exists, for CRIB we still need the
open-coded iterator style process file iterator, and the same is true
for other bpf iterators such as iter/tcp, iter/udp, etc.

The traditional bpf iterator is more like a bpf version of procfs, but
similar to procfs, it is not suitable for CRIB scenarios that need to
obtain large amounts of complex, multi-level in-kernel information.

The following is from previous discussions [1]: 

[1]: https://lore.kernel.org/bpf/[e-mail]/

This is because the context of bpf iterators is fixed and bpf iterators
cannot be nested. This means that a bpf iterator program can only
complete a specific small iterative dump task, and cannot dump
multi-level data.

An example, when we need to dump all the sockets of a process, we need
to iterate over all the files (sockets) of the process, and iterate over
the all packets in the queue of each socket, and iterate over all data
in each packet.

If we use bpf iterator, since the iterator can not be nested, we need to
use socket iterator program to get all the basic information of all
sockets (pass pid as filter), and then use packet iterator program to
get the basic information of all packets of a specific socket (pass pid,
fd as filter), and then use packet data iterator program to get all the
data of a specific packet (pass pid, fd, packet index as filter).

This would be complicated and require a lot of (each iteration)
bpf program startup and exit (leading to poor performance).

By comparison, open coded iterator is much more flexible, we can iterate
in any context, at any time, and iteration can be nested, so we can
achieve more flexible and more elegant dumping through open coded
iterators.

With open coded iterators, all of the above can be done in a single
bpf program, and with nested iterators, everything becomes compact
and simple.

Also, bpf iterators transmit data to user space through seq_file,
which involves a lot of open (bpf_iter_create), read, close syscalls,
context switching, memory copying, and cannot achieve the performance
of using ringbuf.

Signed-off-by: Juntong Deng <[e-mail]>

Juntong Deng (4):
  bpf/crib: Introduce task_file open-coded iterator kfuncs
  selftests/bpf: Add tests for open-coded style process file iterator
  bpf/crib: Add struct file related CRIB kfuncs
  selftests/bpf: Add tests for struct file related CRIB kfuncs.

 kernel/bpf/Makefile                           |   1 +
 kernel/bpf/crib/Makefile                      |   3 +
 kernel/bpf/crib/crib.c                        |  33 ++++
 kernel/bpf/crib/files.c                       | 149 ++++++++++++++++++
 tools/testing/selftests/bpf/prog_tests/crib.c | 126 +++++++++++++++
 .../testing/selftests/bpf/progs/crib_common.h |  25 +++
 .../selftests/bpf/progs/crib_files_failure.c  | 108 +++++++++++++
 .../selftests/bpf/progs/crib_files_success.c  | 119 ++++++++++++++
 8 files changed, 564 insertions(+)
 create mode 100644 kernel/bpf/crib/Makefile
 create mode 100644 kernel/bpf/crib/crib.c
 create mode 100644 kernel/bpf/crib/files.c
 create mode 100644 tools/testing/selftests/bpf/prog_tests/crib.c
 create mode 100644 tools/testing/selftests/bpf/progs/crib_common.h
 create mode 100644 tools/testing/selftests/bpf/progs/crib_files_failure.c
 create mode 100644 tools/testing/selftests/bpf/progs/crib_files_success.c