Message-ID: <a96ca297-ecc3-2bb7-6f76-97d541cd90e5@fb.com>
Date:   Mon, 7 Jun 2021 12:42:51 -0700
From:   Yonghong Song <yhs@...com>
To:     Jiri Olsa <jolsa@...hat.com>
CC:     Jiri Olsa <jolsa@...nel.org>, Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andriin@...com>,
        "Steven Rostedt (VMware)" <rostedt@...dmis.org>,
        <netdev@...r.kernel.org>, <bpf@...r.kernel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...omium.org>, Daniel Xu <dxu@...uu.xyz>,
        Viktor Malik <vmalik@...hat.com>
Subject: Re: [PATCH 15/19] libbpf: Add support to link multi func tracing
 program



On 6/7/21 11:28 AM, Jiri Olsa wrote:
> On Sun, Jun 06, 2021 at 10:49:16PM -0700, Yonghong Song wrote:
>>
>>
>> On 6/5/21 4:10 AM, Jiri Olsa wrote:
>>> Adding support to link multi func tracing program
>>> through link_create interface.
>>>
>>> Adding special types for multi func programs:
>>>
>>>     fentry.multi
>>>     fexit.multi
>>>
>>> so you can define multi func programs like:
>>>
>>>     SEC("fentry.multi/bpf_fentry_test*")
>>>     int BPF_PROG(test1, unsigned long ip, __u64 a, __u64 b, __u64 c, __u64 d, __u64 e, __u64 f)
>>>
>>> that defines test1 to be attached to bpf_fentry_test* functions,
>>> and able to attach ip and 6 arguments.
>>>
>>> If functions are not specified the program needs to be attached
>>> manually.
>>>
>>> Adding new btf id related fields to bpf_link_create_opts and
>>> bpf_link_create to use them.
>>>
>>> Signed-off-by: Jiri Olsa <jolsa@...nel.org>
>>> ---
>>>    tools/lib/bpf/bpf.c    | 11 ++++++-
>>>    tools/lib/bpf/bpf.h    |  4 ++-
>>>    tools/lib/bpf/libbpf.c | 72 ++++++++++++++++++++++++++++++++++++++++++
>>>    3 files changed, 85 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
>>> index 86dcac44f32f..da892737b522 100644
>>> --- a/tools/lib/bpf/bpf.c
>>> +++ b/tools/lib/bpf/bpf.c
>>> @@ -674,7 +674,8 @@ int bpf_link_create(int prog_fd, int target_fd,
>>>    		    enum bpf_attach_type attach_type,
>>>    		    const struct bpf_link_create_opts *opts)
>>>    {
>>> -	__u32 target_btf_id, iter_info_len;
>>> +	__u32 target_btf_id, iter_info_len, multi_btf_ids_cnt;
>>> +	__s32 *multi_btf_ids;
>>>    	union bpf_attr attr;
>>>    	int fd;
>> [...]
>>> @@ -9584,6 +9597,9 @@ static int libbpf_find_attach_btf_id(struct bpf_program *prog, int *btf_obj_fd,
>>>    	if (!name)
>>>    		return -EINVAL;
>>> +	if (prog->prog_flags & BPF_F_MULTI_FUNC)
>>> +		return 0;
>>> +
>>>    	for (i = 0; i < ARRAY_SIZE(section_defs); i++) {
>>>    		if (!section_defs[i].is_attach_btf)
>>>    			continue;
>>> @@ -10537,6 +10553,62 @@ static struct bpf_link *bpf_program__attach_btf_id(struct bpf_program *prog)
>>>    	return (struct bpf_link *)link;
>>>    }
>>> +static struct bpf_link *bpf_program__attach_multi(struct bpf_program *prog)
>>> +{
>>> +	char *pattern = prog->sec_name + prog->sec_def->len;
>>> +	DECLARE_LIBBPF_OPTS(bpf_link_create_opts, opts);
>>> +	enum bpf_attach_type attach_type;
>>> +	int prog_fd, link_fd, cnt, err;
>>> +	struct bpf_link *link = NULL;
>>> +	__s32 *ids = NULL;
>>> +
>>> +	prog_fd = bpf_program__fd(prog);
>>> +	if (prog_fd < 0) {
>>> +		pr_warn("prog '%s': can't attach before loaded\n", prog->name);
>>> +		return ERR_PTR(-EINVAL);
>>> +	}
>>> +
>>> +	err = bpf_object__load_vmlinux_btf(prog->obj, true);
>>> +	if (err)
>>> +		return ERR_PTR(err);
>>> +
>>> +	cnt = btf__find_by_pattern_kind(prog->obj->btf_vmlinux, pattern,
>>> +					BTF_KIND_FUNC, &ids);
>>> +	if (cnt <= 0)
>>> +		return ERR_PTR(-EINVAL);
>>
>> In kernel, looks like we support cnt = 0, here we error out.
>> Should we also error out in the kernel if cnt == 0?
> 
> hum, I'm not what you mean.. what kernel code are you referring to?

I am referring to the following kernel code:

+static int bpf_tracing_multi_attach(struct bpf_prog *prog,
+				    const union bpf_attr *attr)
+{
+	void __user *ubtf_ids = u64_to_user_ptr(attr->link_create.multi_btf_ids);
+	u32 size, i, cnt = attr->link_create.multi_btf_ids_cnt;
+	struct bpf_tracing_multi_link *link = NULL;
+	struct bpf_link_primer link_primer;
+	struct bpf_trampoline *tr = NULL;
+	int err = -EINVAL;
+	u8 nr_args = 0;
+	u32 *btf_ids;
+
+	if (check_multi_prog_type(prog))
+		return -EINVAL;
+
+	size = cnt * sizeof(*btf_ids);
+	btf_ids = kmalloc(size, GFP_USER | __GFP_NOWARN);
+	if (!btf_ids)
+		return -ENOMEM;
+
+	err = -EFAULT;
+	if (ubtf_ids && copy_from_user(btf_ids, ubtf_ids, size))
+		goto out_free;
+
+	link = kzalloc(sizeof(*link), GFP_USER);
+	if (!link)
+		goto out_free;
+
+	for (i = 0; i < cnt; i++) {
+		struct bpf_attach_target_info tgt_info = {};
+
+		err = bpf_check_attach_target(NULL, prog, NULL, btf_ids[i],
+					      &tgt_info);
+		if (err)
+			goto out_free;
+
+		if (ftrace_set_filter_ip(&link->ops, tgt_info.tgt_addr, 0, 0))
+			goto out_free;
+
+		if (nr_args < tgt_info.fmodel.nr_args)
+			nr_args = tgt_info.fmodel.nr_args;
+	}
+
+	tr = bpf_trampoline_multi_alloc();
+	if (!tr)
+		goto out_free;
+
+	bpf_func_model_nargs(&tr->func.model, nr_args);
+
+	err = bpf_trampoline_link_prog(prog, tr);
+	if (err)
+		goto out_free;
+
+	err = register_ftrace_direct_multi(&link->ops, (unsigned long) 
tr->cur_image->image);
+	if (err)
+		goto out_free;
+
+	bpf_link_init(&link->link, BPF_LINK_TYPE_TRACING_MULTI,
+		      &bpf_tracing_multi_link_lops, prog);
+	link->attach_type = prog->expected_attach_type;
+
+	err = bpf_link_prime(&link->link, &link_primer);
+	if (err)
+		goto out_unlink;
+
+	link->tr = tr;
+	/* Take extra ref so we are even with progs added by link_update. */
+	bpf_prog_inc(prog);
+	return bpf_link_settle(&link_primer);
+
+out_unlink:
+	unregister_ftrace_direct_multi(&link->ops);
+out_free:
+	kfree(tr);
+	kfree(btf_ids);
+	kfree(link);
+	return err;
+}
+

Looks like cnt = 0 is okay in bpf_tracing_multi_attach().

> 
> thanks,
> jirka
> 

Powered by blists - more mailing lists