On 4/17/20 3:54 AM, Alan Maguire wrote:
On Wed, 15 Apr 2020, David Ahern wrote:
On 4/15/20 1:27 PM, Yonghong Song wrote:
As there are some discussions regarding to the kernel interface/steps to
create file/anonymous dumpers, I think it will be beneficial for
discussion with this work in progress.
Motivation:
The current way to dump kernel data structures mostly:
1. /proc system
2. various specific tools like "ss" which requires kernel support.
3. drgn
The dropback for the first two is that whenever you want to dump more, you
need change the kernel. For example, Martin wants to dump socket local
If kernel support is needed for bpfdump of kernel data structures, you
are not really solving the kernel support problem. i.e., to dump
ipv4_route's you need to modify the relevant proc show function.
I need to dig into this patchset a bit more, but if there is
a need for in-kernel BTF-based structure dumping I've got a
work-in-progress patchset that does this by generalizing the code
that deals with seq output in the verifier. I've posted it
as an RFC in case it has anything useful to offer here:
https://lore.kernel.org/bpf/1587120160-3030-1-git-send-email-alan.maguire@xxxxxxxxxx/T/#t
The idea is that by using different callback function we can achieve
seq, snprintf or other output in-kernel using the kernel BTF data.
I created one consumer as a proof-of-concept; it's a printk pointer
format specifier. Since the dump format is determined in kernel
it's a bit constrained format-wise, but may be good enough for
some cases.
The bpfdump work and here in-kernel btf dumping are different.
The bpfdump BPF programs are triggered with a user syscall, e.g.,
cat /sys/kernel/bpfdump/task/my_dumper (also calling open())
or when user open() an anonymous dumper.
The BPF program can "print" some data through bpf_seq_printf()
helper. These printed data will be received by user space
through read() syscall.
Your work is greater as it makes kernel print more readable.
There is no overlap between your work and bpfdump.
