[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e6e8ee19-4c1e-1284-4bbb-11c5f545f3d1@fb.com>
Date: Fri, 10 Apr 2020 16:25:23 -0700
From: Yonghong Song <yhs@...com>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
CC: Andrii Nakryiko <andriin@...com>, bpf <bpf@...r.kernel.org>,
Martin KaFai Lau <kafai@...com>,
Networking <netdev@...r.kernel.org>,
Alexei Starovoitov <ast@...com>,
Daniel Borkmann <daniel@...earbox.net>,
Kernel Team <kernel-team@...com>
Subject: Re: [RFC PATCH bpf-next 03/16] bpf: provide a way for targets to
register themselves
On 4/10/20 3:25 PM, Andrii Nakryiko wrote:
> On Wed, Apr 8, 2020 at 4:26 PM Yonghong Song <yhs@...com> wrote:
>>
>> Here, the target refers to a particular data structure
>> inside the kernel we want to dump. For example, it
>> can be all task_structs in the current pid namespace,
>> or it could be all open files for all task_structs
>> in the current pid namespace.
>>
>> Each target is identified with the following information:
>> target_rel_path <=== relative path to /sys/kernel/bpfdump
>> target_proto <=== kernel func proto which represents
>> bpf program signature for this target
>> seq_ops <=== seq_ops for seq_file operations
>> seq_priv_size <=== seq_file private data size
>> target_feature <=== target specific feature which needs
>> handling outside seq_ops.
>>
>> The target relative path is a relative directory to /sys/kernel/bpfdump/.
>> For example, it could be:
>> task <=== all tasks
>> task/file <=== all open files under all tasks
>> ipv6_route <=== all ipv6_routes
>> tcp6/sk_local_storage <=== all tcp6 socket local storages
>> foo/bar/tar <=== all tar's in bar in foo
>>
>> The "target_feature" is mostly used for reusing existing seq_ops.
>> For example, for /proc/net/<> stats, the "net" namespace is often
>> stored in file private data. The target_feature enables bpf based
>> dumper to set "net" properly for itself before calling shared
>> seq_ops.
>>
>> bpf_dump_reg_target() is implemented so targets
>> can register themselves. Currently, module is not
>> supported, so there is no bpf_dump_unreg_target().
>> The main reason is that BTF is not available for modules
>> yet.
>>
>> Since target might call bpf_dump_reg_target() before
>> bpfdump mount point is created, __bpfdump_init()
>> may be called in bpf_dump_reg_target() as well.
>>
>> The file-based dumpers will be regular files under
>> the specific target directory. For example,
>> task/my1 <=== dumper "my1" iterates through all tasks
>> task/file/my2 <=== dumper "my2" iterates through all open files
>> under all tasks
>>
>> Signed-off-by: Yonghong Song <yhs@...com>
>> ---
>> include/linux/bpf.h | 4 +
>> kernel/bpf/dump.c | 190 +++++++++++++++++++++++++++++++++++++++++++-
>> 2 files changed, 193 insertions(+), 1 deletion(-)
>>
>
> [...]
>
>> +
>> +static int dumper_unlink(struct inode *dir, struct dentry *dentry)
>> +{
>> + kfree(d_inode(dentry)->i_private);
>> + return simple_unlink(dir, dentry);
>> +}
>> +
>> +static const struct inode_operations bpf_dir_iops = {
>
> noticed this reading next patch. It should probably be called
> bpfdump_dir_iops to avoid confusion with bpf_dir_iops of BPF FS in
> kernel/bpf/inode.c?
make sense. originally probably copied from inode.c and did not
change that.
>
>> + .lookup = simple_lookup,
>> + .unlink = dumper_unlink,
>> +};
>> +
>
> [...]
>
Powered by blists - more mailing lists