summaryrefslogtreecommitdiff
path: root/kernel/bpf/cgroup.c
diff options
context:
space:
mode:
authorYiFei Zhu <zhuyifei@google.com>2020-07-24 07:47:42 +0300
committerAlexei Starovoitov <ast@kernel.org>2020-07-26 06:16:35 +0300
commit9e5bd1f7633bc1c3c8b25496eedfeced6d2675ff (patch)
treed2cbd43bfa673721b3b0f798a6bcc65146f7c718 /kernel/bpf/cgroup.c
parentd4a89c1eb81431479664029bcdec593dbf23385f (diff)
downloadlinux-9e5bd1f7633bc1c3c8b25496eedfeced6d2675ff.tar.xz
selftests/bpf: Test CGROUP_STORAGE map can't be used by multiple progs
The current assumption is that the lifetime of a cgroup storage is tied to the program's attachment. The storage is created in cgroup_bpf_attach, and released upon cgroup_bpf_detach and cgroup_bpf_release. Because the current semantics is that each attachment gets a completely independent cgroup storage, and you can have multiple programs attached to the same (cgroup, attach type) pair, the key of the CGROUP_STORAGE map, looking up the map with this pair could yield multiple storages, and that is not permitted. Therefore, the kernel verifier checks that two programs cannot share the same CGROUP_STORAGE map, even if they have different expected attach types, considering that the actual attach type does not always have to be equal to the expected attach type. The test creates a CGROUP_STORAGE map and make it shared across two different programs, one cgroup_skb/egress and one /ingress. It asserts that the two programs cannot be both loaded, due to verifier failure from the above reason. Signed-off-by: YiFei Zhu <zhuyifei@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/30a6b0da67ae6b0296c4d511bfb19c5f3d035916.1595565795.git.zhuyifei@google.com
Diffstat (limited to 'kernel/bpf/cgroup.c')
0 files changed, 0 insertions, 0 deletions