BPF List
 help / color / mirror / Atom feed
From: Paul Houssel <paulhoussel2@gmail.com>
To: paul.houssel@orange.com, "Andrii Nakryiko" <andrii@kernel.org>,
	"Yonghong Song" <yonghong.song@linux.dev>,
	"Paul Houssel" <paulhoussel2@gmail.com>,
	"KP Singh" <kpsingh@kernel.org>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Song Liu" <song@kernel.org>,
	"Martin KaFai Lau" <martin.lau@kernel.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Florian Westphal" <fw@strlen.de>,
	"T.J. Mercier" <tjmercier@google.com>,
	"Li RongQing" <lirongqing@baidu.com>,
	"Paul Chaignon" <paul.chaignon@gmail.com>,
	"D. Wythe" <alibuda@linux.alibaba.com>,
	"Jakub Kicinski" <kuba@kernel.org>
Cc: "Stanislav Fomichev" <sdf@fomichev.me>, bpf@vger.kernel.org
Subject: [PATCH v3 0/2]  Introduce CONFIG_CGROUP_LSM_NUM to render BPF_LSM_CGROUP attachment limit configurable
Date: Wed,  6 May 2026 17:05:45 +0200	[thread overview]
Message-ID: <20260506150547.767315-1-paulhoussel2@gmail.com> (raw)

In include/linux/bpf-cgroup-defs.h, CGROUP_LSM_NUM defines the maximum
number of BPF_PROG_TYPE_LSM programs that can be simultaneously attached
using the BPF_LSM_CGROUP attachment type. It is currently hardcoded to 10.

This limit was introduced in 'commit c0e19f2c9a3e ("bpf: minimize number
of allocated lsm slots per program")' in the first patch implementing
BPF_LSM_CGROUP attachment, and has not been changed since. Rather than
reserving one slot per LSM hook (a 1:1 static mapping across all 211
possible available hooks at that time), it introduced a dynamic scheme
where only 10 slots exist per cgroup allocated on demand.

In practice, eBPF-based tools may exceed this limit. I therefore propose
making CGROUP_LSM_NUM a Kconfig option so that users can tune it to their
requirements, rather than being constrained by static hardcoded default
that has been arbitrarily decided on the first implementation of this
attachment type. On the other hand some uses cases may be interest to
limit the number of attachments to a lower value than 10 to prevent too
much memory overhead.

Modifying this limit has been dicussed previously in
https://lore.kernel.org/bpf/20220408225628.oog4a3qteauhqkdn@kafai-mbp.dhcp.thefacebook.com/,
where the same thought on this limit being too small was being shared as
well. Furthermore, this discussion seems to have yielded inconclusive
about to render it dynamic, without a fixed array size.

Changes since V3:
	- refactor test eBPF programs by using a macro (patch 2)
	- improve the kconfig help text by elaborating on the memory
	  overhead (patch 1)
	- link to V2:
	https://lore.kernel.org/bpf/20260506131257.713895-1-paulhoussel2@gmail.com/



Paul Houssel (2):
  bpf: render CGROUP_LSM_NUM configurable as a KConfig
  selftests/bpf: add tests to verify the enforcement of
    CONFIG_CGROUP_LSM_NUM

 include/linux/bpf-cgroup-defs.h               |  2 +-
 kernel/bpf/Kconfig                            | 19 ++++++
 tools/testing/selftests/bpf/config            |  1 +
 .../selftests/bpf/prog_tests/cgroup_lsm_num.c | 60 +++++++++++++++++++
 .../selftests/bpf/progs/cgroup_lsm_num.c      | 46 ++++++++++++++
 5 files changed, 127 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/bpf/prog_tests/cgroup_lsm_num.c
 create mode 100644 tools/testing/selftests/bpf/progs/cgroup_lsm_num.c

-- 
2.54.0


             reply	other threads:[~2026-05-06 15:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-06 15:05 Paul Houssel [this message]
2026-05-06 15:05 ` [PATCH v3 1/2] bpf: render CGROUP_LSM_NUM configurable as a KConfig Paul Houssel
2026-05-06 15:52   ` bot+bpf-ci
2026-05-06 16:11     ` Paul Chaignon
2026-05-06 21:08   ` sashiko-bot
2026-05-07 16:39     ` Paul Houssel
2026-05-08 22:16       ` Alexei Starovoitov
2026-05-06 15:05 ` [PATCH v3 2/2] selftests/bpf: add tests to verify the enforcement of CONFIG_CGROUP_LSM_NUM Paul Houssel
2026-05-06 16:05   ` Paul Chaignon
2026-05-06 21:24   ` sashiko-bot
2026-05-06 16:13 ` [PATCH v3 0/2] Introduce CONFIG_CGROUP_LSM_NUM to render BPF_LSM_CGROUP attachment limit configurable Paul Chaignon

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=20260506150547.767315-1-paulhoussel2@gmail.com \
    --to=paulhoussel2@gmail.com \
    --cc=alibuda@linux.alibaba.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=christian.koenig@amd.com \
    --cc=fw@strlen.de \
    --cc=kpsingh@kernel.org \
    --cc=kuba@kernel.org \
    --cc=lirongqing@baidu.com \
    --cc=martin.lau@kernel.org \
    --cc=paul.chaignon@gmail.com \
    --cc=paul.houssel@orange.com \
    --cc=sdf@fomichev.me \
    --cc=song@kernel.org \
    --cc=tjmercier@google.com \
    --cc=yonghong.song@linux.dev \
    /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