Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Martynas Pumputis <m@lambda.lt>
To: netdev@vger.kernel.org
Cc: haliu@redhat.com, stephen@networkplumber.org, dsahern@gmail.com,
m@lambda.lt
Subject: [PATCH iproute2] libbpf: fix attach of prog with multiple sections
Date: Mon, 5 Jul 2021 14:43:07 +0200 [thread overview]
Message-ID: <20210705124307.201303-1-m@lambda.lt> (raw)
When BPF programs which consists of multiple executable sections via
iproute2+libbpf (configured with LIBBPF_FORCE=on), we noticed that a
wrong section can be attached to a device. E.g.:
# tc qdisc replace dev lxc_health clsact
# tc filter replace dev lxc_health ingress prio 1 \
handle 1 bpf da obj bpf_lxc.o sec from-container
# tc filter show dev lxc_health ingress filter protocol all
pref 1 bpf chain 0 filter protocol all pref 1 bpf chain 0
handle 0x1 bpf_lxc.o:[__send_drop_notify] <-- WRONG SECTION
direct-action not_in_hw id 38 tag 7d891814eda6809e jited
After taking a closer look into load_bpf_object() in lib/bpf_libbpf.c,
we noticed that the filter used in the program iterator does not check
whether a program section name matches a requested section name
(cfg->section). This can lead to a wrong prog FD being used to attach
the program.
Fixes: 6d61a2b55799 ("lib: add libbpf support")
Signed-off-by: Martynas Pumputis <m@lambda.lt>
---
lib/bpf_libbpf.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/lib/bpf_libbpf.c b/lib/bpf_libbpf.c
index d05737a4..f76b90d2 100644
--- a/lib/bpf_libbpf.c
+++ b/lib/bpf_libbpf.c
@@ -267,10 +267,12 @@ static int load_bpf_object(struct bpf_cfg_in *cfg)
}
bpf_object__for_each_program(p, obj) {
+ bool prog_to_attach = !prog && cfg->section &&
+ !strcmp(get_bpf_program__section_name(p), cfg->section);
+
/* Only load the programs that will either be subsequently
* attached or inserted into a tail call map */
- if (find_legacy_tail_calls(p, obj) < 0 && cfg->section &&
- strcmp(get_bpf_program__section_name(p), cfg->section)) {
+ if (find_legacy_tail_calls(p, obj) < 0 && !prog_to_attach) {
ret = bpf_program__set_autoload(p, false);
if (ret)
return -EINVAL;
@@ -279,7 +281,8 @@ static int load_bpf_object(struct bpf_cfg_in *cfg)
bpf_program__set_type(p, cfg->type);
bpf_program__set_ifindex(p, cfg->ifindex);
- if (!prog)
+
+ if (prog_to_attach)
prog = p;
}
--
2.32.0
next reply other threads:[~2021-07-05 12:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-05 12:43 Martynas Pumputis [this message]
2021-07-06 2:44 ` Hangbin Liu
2021-07-20 20:27 ` Andrii Nakryiko
2021-07-21 14:47 ` Martynas Pumputis
2021-07-21 14:59 ` David Ahern
2021-07-21 15:27 ` Martynas Pumputis
2021-07-23 4:01 ` Andrii Nakryiko
2021-07-23 4:41 ` Hangbin Liu
2021-07-23 4:51 ` Andrii Nakryiko
2021-07-23 7:55 ` Hangbin Liu
2021-07-23 16:09 ` Andrii Nakryiko
2021-07-24 8:12 ` Hangbin Liu
2021-07-24 0:12 ` David Ahern
2021-07-24 0:25 ` Andrii Nakryiko
2021-07-26 13:58 ` David Ahern
2021-07-26 15:13 ` Andrii Nakryiko
2021-07-27 2:51 ` David Ahern
2021-07-27 19:05 ` Andrii Nakryiko
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=20210705124307.201303-1-m@lambda.lt \
--to=m@lambda.lt \
--cc=dsahern@gmail.com \
--cc=haliu@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
--subject='Re: [PATCH iproute2] libbpf: fix attach of prog with multiple sections' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).