All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Marchevsky <davemarchevsky@fb.com>
To: <bpf@vger.kernel.org>
Cc: <netdev@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Dave Marchevsky <davemarchevsky@fb.com>
Subject: [PATCH bpf-next v2 0/1] Refactor cgroup_bpf internals to use more specific attach_type
Date: Thu, 19 Aug 2021 02:24:19 -0700	[thread overview]
Message-ID: <20210819092420.1984861-1-davemarchevsky@fb.com> (raw)

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(-)

-- 
2.30.2


             reply	other threads:[~2021-08-19  9:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-19  9:24 Dave Marchevsky [this message]
2021-08-19  9:24 ` [PATCH bpf-next v2 1/1] bpf: migrate cgroup_bpf to internal cgroup_bpf_attach_type enum Dave Marchevsky
2021-08-24  1:00 ` [PATCH bpf-next v2 0/1] Refactor cgroup_bpf internals to use more specific attach_type patchwork-bot+netdevbpf

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=20210819092420.1984861-1-davemarchevsky@fb.com \
    --to=davemarchevsky@fb.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=songliubraving@fb.com \
    --cc=yhs@fb.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 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.