From: Martin KaFai Lau <martin.lau@linux.dev>
To: Kui-Feng Lee <kuifeng@meta.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, song@kernel.org,
kernel-team@meta.com, andrii@kernel.org, sdf@google.com
Subject: Re: [PATCH bpf-next v9 4/8] libbpf: Create a bpf_link in bpf_map__attach_struct_ops().
Date: Tue, 21 Mar 2023 10:36:40 -0700 [thread overview]
Message-ID: <0c4dc26d-a2d9-bd65-b151-e3bf8bae0660@linux.dev> (raw)
In-Reply-To: <20230320192410.1624645-5-kuifeng@meta.com>
On 3/20/23 12:24 PM, Kui-Feng Lee wrote:
> struct bpf_link *bpf_map__attach_struct_ops(const struct bpf_map *map)
> {
> - struct bpf_struct_ops *st_ops;
> - struct bpf_link *link;
> - __u32 i, zero = 0;
> - int err;
> + struct bpf_link_struct_ops *link;
> + __u32 zero = 0;
> + int err, fd;
>
> if (!bpf_map__is_struct_ops(map) || map->fd == -1)
> return libbpf_err_ptr(-EINVAL);
> @@ -11596,31 +11637,32 @@ struct bpf_link *bpf_map__attach_struct_ops(const struct bpf_map *map)
> if (!link)
> return libbpf_err_ptr(-EINVAL);
>
> - st_ops = map->st_ops;
> - for (i = 0; i < btf_vlen(st_ops->type); i++) {
> - struct bpf_program *prog = st_ops->progs[i];
> - void *kern_data;
> - int prog_fd;
> + /* kern_vdata should be prepared during the loading phase. */
> + err = bpf_map_update_elem(map->fd, &zero, map->st_ops->kern_vdata, 0);
> + if (err && err != -EBUSY) {
> + free(link);
> + return libbpf_err_ptr(err);
> + }
>
> - if (!prog)
> - continue;
> + link->link.detach = bpf_link__detach_struct_ops;
>
> - prog_fd = bpf_program__fd(prog);
> - kern_data = st_ops->kern_vdata + st_ops->kern_func_off[i];
> - *(unsigned long *)kern_data = prog_fd;
> + if (!(map->def.map_flags & BPF_F_LINK)) {
hmm... This still does not look right. 'err' could be -EBUSY here and should not
be treated as success for non BPF_F_LINK case. The above 'err && err != -EBUSY'
check should also consider the BPF_F_LINK map_flags.
> + /* w/o a real link */
> + link->link.fd = map->fd;
> + link->map_fd = -1;
> + return &link->link;
> }
>
> - err = bpf_map_update_elem(map->fd, &zero, st_ops->kern_vdata, 0);
> - if (err) {
> - err = -errno;
> + fd = bpf_link_create(map->fd, 0, BPF_STRUCT_OPS, NULL);
> + if (fd < 0) {
> free(link);
> - return libbpf_err_ptr(err);
> + return libbpf_err_ptr(fd);
> }
>
> - link->detach = bpf_link__detach_struct_ops;
> - link->fd = map->fd;
> + link->link.fd = fd;
> + link->map_fd = map->fd;
>
> - return link;
> + return &link->link;
> }
next prev parent reply other threads:[~2023-03-21 17:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-20 19:24 [PATCH bpf-next v9 0/8] Transit between BPF TCP congestion controls Kui-Feng Lee
2023-03-20 19:24 ` [PATCH bpf-next v9 1/8] bpf: Retire the struct_ops map kvalue->refcnt Kui-Feng Lee
2023-03-20 19:24 ` [PATCH bpf-next v9 2/8] net: Update an existing TCP congestion control algorithm Kui-Feng Lee
2023-03-20 19:24 ` [PATCH bpf-next v9 3/8] bpf: Create links for BPF struct_ops maps Kui-Feng Lee
2023-03-20 19:24 ` [PATCH bpf-next v9 4/8] libbpf: Create a bpf_link in bpf_map__attach_struct_ops() Kui-Feng Lee
2023-03-21 17:36 ` Martin KaFai Lau [this message]
2023-03-20 19:24 ` [PATCH bpf-next v9 5/8] bpf: Update the struct_ops of a bpf_link Kui-Feng Lee
2023-03-20 19:24 ` [PATCH bpf-next v9 6/8] libbpf: Update a bpf_link with another struct_ops Kui-Feng Lee
2023-03-20 19:24 ` [PATCH bpf-next v9 7/8] libbpf: Use .struct_ops.link section to indicate a struct_ops with a link Kui-Feng Lee
2023-03-20 19:24 ` [PATCH bpf-next v9 8/8] selftests/bpf: Test switching TCP Congestion Control algorithms Kui-Feng Lee
2023-03-20 20:15 ` [PATCH bpf-next v9 0/8] Transit between BPF TCP congestion controls Kui-Feng Lee
-- strict thread matches above, loose matches on Subject: below --
2023-03-20 19:56 Kui-Feng Lee
2023-03-20 19:56 ` [PATCH bpf-next v9 4/8] libbpf: Create a bpf_link in bpf_map__attach_struct_ops() Kui-Feng Lee
2023-03-21 17:49 ` Martin KaFai Lau
2023-03-21 23:03 ` Kui-Feng Lee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0c4dc26d-a2d9-bd65-b151-e3bf8bae0660@linux.dev \
--to=martin.lau@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=kernel-team@meta.com \
--cc=kuifeng@meta.com \
--cc=sdf@google.com \
--cc=song@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.