On 4/17/20 8:02 AM, Alan Maguire wrote:
On Wed, 15 Apr 2020, Yonghong Song wrote:
On 4/15/20 7:23 PM, 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.
Yes, as mentioned two paragraphs below. kernel change is required.
The tradeoff is that this is a one-time investment. Once kernel change
is in place, printing new fields (in most cases except new fields
which need additional locks etc.) no need for kernel change any more.
One thing I struggled with initially when reading the cover
letter was understanding how BPF dumper programs get run.
Patch 7 deals with that I think and the answer seems to be to
create additional seq file infrastructure to the exisiting
one which executes the BPF dumper programs where appropriate.
Have I got this right? I guess more lightweight methods
Yes. The reason is that some data structures like bpf_map, task, or
task/file do not have existing seq_ops infrastructure so I created
new ones to iterate them.
such as instrumenting functions associated with an existing /proc
dumper are a bit too messy?
We did use existing seq_ops from /proc/net/ipv6_route and
/proc/net/netlink as an example. In the future, we will do
/proc/net/tcp[6] and
/proc/net/udp[6] which will reuse existing seq_ops with slight
modifications.
