From: YiFei Zhu <zhuyifei1999@gmail.com>
To: bpf@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Stanislav Fomichev <sdf@google.com>,
Mahesh Bandewar <maheshb@google.com>,
Roman Gushchin <guro@fb.com>, YiFei Zhu <zhuyifei@google.com>
Subject: [RFC PATCH bpf-next 4/5] selftests/bpf: Test CGROUP_STORAGE behavior on shared egress + ingress
Date: Wed, 1 Jul 2020 17:13:57 -0500 [thread overview]
Message-ID: <a81fb721c7e653130399ec52ee7cda7bdefddc2b.1593638618.git.zhuyifei@google.com> (raw)
In-Reply-To: <cover.1593638618.git.zhuyifei@google.com>
From: YiFei Zhu <zhuyifei@google.com>
This mirrors the original egress-only test. The cgroup_storage is
now extended to have two packet counters, one for egress and one
for ingress. The behavior of the counters are exactly the same as
the original egress-only test, only that the total number of
invocations doubles from having both egress and ingress being
counted.
The field attach_type in the map key is ignored in the kernel;
however, keeping it is pointless here and we are demonstrating the
expected usage of the map, so it is removed. That said, keeping the
field will not fail the test, for backwards compatibility reasons.
In other words, the original egress-only test is not affected by
the change in CGROUP_STORAGE behavior and will pass in both cases.
Signed-off-by: YiFei Zhu <zhuyifei@google.com>
---
.../bpf/prog_tests/cg_storage_multi.c | 77 +++++++++++++++++--
1 file changed, 71 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests/bpf/prog_tests/cg_storage_multi.c b/tools/testing/selftests/bpf/prog_tests/cg_storage_multi.c
index 140fb42929b5..0047dd485104 100644
--- a/tools/testing/selftests/bpf/prog_tests/cg_storage_multi.c
+++ b/tools/testing/selftests/bpf/prog_tests/cg_storage_multi.c
@@ -26,7 +26,6 @@ static bool assert_storage(struct bpf_map *map, const char *cgroup_path,
map_fd = bpf_map__fd(map);
key.cgroup_inode_id = get_cgroup_id(cgroup_path);
- key.attach_type = BPF_CGROUP_INET_EGRESS;
if (CHECK_FAIL(bpf_map_lookup_elem(map_fd, &key, &value) < 0))
return true;
if (CHECK_FAIL(memcmp(&value, expected, sizeof(struct cgroup_value))))
@@ -44,7 +43,6 @@ static bool assert_storage_noexist(struct bpf_map *map, const char *cgroup_path)
map_fd = bpf_map__fd(map);
key.cgroup_inode_id = get_cgroup_id(cgroup_path);
- key.attach_type = BPF_CGROUP_INET_EGRESS;
if (CHECK_FAIL(bpf_map_lookup_elem(map_fd, &key, &value) == 0))
return true;
if (CHECK_FAIL(errno != ENOENT))
@@ -147,16 +145,83 @@ static void test_egress_only(int parent_cgroup_fd, int child_cgroup_fd)
static void test_egress_ingress(int parent_cgroup_fd, int child_cgroup_fd)
{
struct cg_storage_multi_egress_ingress *obj;
+ struct cgroup_value expected_cgroup_value;
+ int err;
if (!test__start_subtest("egress_ingress"))
return;
- /* Cannot load both programs due to verifier failure:
- * "only one cgroup storage of each type is allowed"
- */
obj = cg_storage_multi_egress_ingress__open_and_load();
- if (CHECK_FAIL(obj || errno != EBUSY))
+ if (CHECK_FAIL(!obj))
return;
+
+ /* Attach to parent cgroup, trigger packet from child.
+ * Assert that there is two runs, one with parent cgroup egress and
+ * one with parent cgroup ingress.
+ * Also assert that child cgroup's storage does not exist
+ */
+ err = bpf_prog_attach(bpf_program__fd(obj->progs.egress),
+ parent_cgroup_fd,
+ BPF_CGROUP_INET_EGRESS, BPF_F_ALLOW_MULTI);
+ if (CHECK_FAIL(err))
+ goto close_bpf_object;
+ err = bpf_prog_attach(bpf_program__fd(obj->progs.ingress),
+ parent_cgroup_fd,
+ BPF_CGROUP_INET_INGRESS, BPF_F_ALLOW_MULTI);
+ if (CHECK_FAIL(err))
+ goto close_bpf_object;
+ err = connect_send(CHILD_CGROUP);
+ if (CHECK_FAIL(err))
+ goto close_bpf_object;
+ if (CHECK_FAIL(obj->bss->invocations != 2))
+ goto close_bpf_object;
+ expected_cgroup_value = (struct cgroup_value) {
+ .egress_pkts = 1,
+ .ingress_pkts = 1,
+ };
+ if (CHECK_FAIL(assert_storage(obj->maps.cgroup_storage,
+ PARENT_CGROUP, &expected_cgroup_value)))
+ goto close_bpf_object;
+ if (CHECK_FAIL(assert_storage_noexist(obj->maps.cgroup_storage,
+ CHILD_CGROUP)))
+ goto close_bpf_object;
+
+ /* Attach to parent and child cgroup, trigger packet from child.
+ * Assert that there is four additional runs, parent cgroup egress and
+ * ingress, child cgroup egress and ingress.
+ */
+ err = bpf_prog_attach(bpf_program__fd(obj->progs.egress),
+ child_cgroup_fd,
+ BPF_CGROUP_INET_EGRESS, BPF_F_ALLOW_MULTI);
+ if (CHECK_FAIL(err))
+ goto close_bpf_object;
+ err = bpf_prog_attach(bpf_program__fd(obj->progs.ingress),
+ child_cgroup_fd,
+ BPF_CGROUP_INET_INGRESS, BPF_F_ALLOW_MULTI);
+ if (CHECK_FAIL(err))
+ goto close_bpf_object;
+ err = connect_send(CHILD_CGROUP);
+ if (CHECK_FAIL(err))
+ goto close_bpf_object;
+ if (CHECK_FAIL(obj->bss->invocations != 6))
+ goto close_bpf_object;
+ expected_cgroup_value = (struct cgroup_value) {
+ .egress_pkts = 2,
+ .ingress_pkts = 2,
+ };
+ if (CHECK_FAIL(assert_storage(obj->maps.cgroup_storage,
+ PARENT_CGROUP, &expected_cgroup_value)))
+ goto close_bpf_object;
+ expected_cgroup_value = (struct cgroup_value) {
+ .egress_pkts = 1,
+ .ingress_pkts = 1,
+ };
+ if (CHECK_FAIL(assert_storage(obj->maps.cgroup_storage,
+ CHILD_CGROUP, &expected_cgroup_value)))
+ goto close_bpf_object;
+
+close_bpf_object:
+ cg_storage_multi_egress_ingress__destroy(obj);
}
void test_cg_storage_multi(void)
--
2.27.0
next prev parent reply other threads:[~2020-07-01 22:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-01 22:13 [RFC PATCH bpf-next 0/5] Make BPF CGROUP_STORAGE map usable by different programs at once YiFei Zhu
2020-07-01 22:13 ` [RFC PATCH bpf-next 1/5] selftests/bpf: Add test for CGROUP_STORAGE map on multiple attaches YiFei Zhu
2020-07-01 22:13 ` [RFC PATCH bpf-next 2/5] selftests/bpf: Test CGROUP_STORAGE map can't be used by multiple progs YiFei Zhu
2020-07-01 22:13 ` [RFC PATCH bpf-next 3/5] bpf: Make cgroup storages shared across attaches on the same cgroup YiFei Zhu
2020-07-02 0:17 ` Roman Gushchin
2020-07-02 0:55 ` YiFei Zhu
2020-07-01 22:13 ` YiFei Zhu [this message]
2020-07-01 22:13 ` [RFC PATCH bpf-next 5/5] Documentation/bpf: Document CGROUP_STORAGE map type YiFei Zhu
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=a81fb721c7e653130399ec52ee7cda7bdefddc2b.1593638618.git.zhuyifei@google.com \
--to=zhuyifei1999@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=guro@fb.com \
--cc=maheshb@google.com \
--cc=sdf@google.com \
--cc=zhuyifei@google.com \
/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 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).