| Message ID | 20210819092420.1984861-1-davemarchevsky@fb.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Refactor cgroup_bpf internals to use more specific attach_type | expand |
Hello: This patch was applied to bpf/bpf-next.git (refs/heads/master): On Thu, 19 Aug 2021 02:24:19 -0700 you wrote: > The cgroup_bpf struct has a few arrays (effective, progs, and flags) of > size MAX_BPF_ATTACH_TYPE. These are meant to separate progs by their > attach type, currently represented by the bpf_attach_type enum. > > There are some bpf_attach_type values which are not valid attach types > for cgroup bpf programs. Programs with these attach types will never be > handled by cgroup_bpf_{attach,detach} and thus will never be held in > cgroup_bpf structs. Even if such programs did make it into their > reserved slot in those arrays, they would never be executed. > > [...] Here is the summary with links: - [bpf-next,v2,1/1] bpf: migrate cgroup_bpf to internal cgroup_bpf_attach_type enum https://git.kernel.org/bpf/bpf-next/c/4ed589a27893 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
The cgroup_bpf struct has a few arrays (effective, progs, and flags) of size MAX_BPF_ATTACH_TYPE. These are meant to separate progs by their attach type, currently represented by the bpf_attach_type enum. There are some bpf_attach_type values which are not valid attach types for cgroup bpf programs. Programs with these attach types will never be handled by cgroup_bpf_{attach,detach} and thus will never be held in cgroup_bpf structs. Even if such programs did make it into their reserved slot in those arrays, they would never be executed. Accordingly we can migrate to a new internal cgroup_bpf-specific enum for these arrays, saving some bytes per cgroup and making it more obvious which BPF programs belong there. netns_bpf_attach_type is an existing example of this pattern, let's do similar for cgroup_bpf. v1->v2: Address Daniel's comments * Reverse xmas tree ordering for def changes * Helper macro to reduce to_cgroup_bpf_attach_type boilerplate * checkpatch.pl complains: "ERROR: Macros with complex values should be enclosed in parentheses". Found some existing macros (do 'git grep "define case"') which get same complaint. Think it's fine to keep as-is since it's immediately undef'd. * Remove CG_BPF_ prefix from cgroup_bpf_attach_type * Although I agree that the prefix is redundant, the de-prefixed names feel a bit too 'general' given the internal use of the enum. e.g. when someone sees CGROUP_INET6_BIND it's not obvious that it should only be used in certain ways internally. * Don't feel strongly about this, just my thoughts as a noob to the internals. * Rebase onto latest bpf-next/master * No significant conflicts, some small boilerplate adjustments needed to catch up to Andrii's "bpf: Refactor BPF_PROG_RUN_ARRAY family of macros into functions" change Dave Marchevsky (1): bpf: migrate cgroup_bpf to internal cgroup_bpf_attach_type enum include/linux/bpf-cgroup.h | 183 ++++++++++++++++++++++----------- include/uapi/linux/bpf.h | 2 +- kernel/bpf/cgroup.c | 156 ++++++++++++++++------------ net/ipv4/af_inet.c | 6 +- net/ipv4/udp.c | 2 +- net/ipv6/af_inet6.c | 6 +- net/ipv6/udp.c | 2 +- tools/include/uapi/linux/bpf.h | 2 +- 8 files changed, 227 insertions(+), 132 deletions(-)