From: Paul Chaignon <paul.chaignon@gmail.com>
To: Paul Houssel <paulhoussel2@gmail.com>
Cc: paul.houssel@orange.com, "Andrii Nakryiko" <andrii@kernel.org>,
"Yonghong Song" <yonghong.song@linux.dev>,
"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>,
"D. Wythe" <alibuda@linux.alibaba.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Stanislav Fomichev" <sdf@fomichev.me>,
bpf@vger.kernel.org
Subject: Re: [PATCH v3 0/2] Introduce CONFIG_CGROUP_LSM_NUM to render BPF_LSM_CGROUP attachment limit configurable
Date: Wed, 6 May 2026 18:13:16 +0200 [thread overview]
Message-ID: <aftonBG4vXaieFLp@mail.gmail.com> (raw)
In-Reply-To: <20260506150547.767315-1-paulhoussel2@gmail.com>
On Wed, May 06, 2026 at 05:05:45PM +0200, Paul Houssel wrote:
> 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/
We typically keep the full changelogs (with each version). That can
help among other things to get a sense of whether the reviews are
converging.
>
>
>
> 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
>
prev parent reply other threads:[~2026-05-06 16:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-06 15:05 [PATCH v3 0/2] Introduce CONFIG_CGROUP_LSM_NUM to render BPF_LSM_CGROUP attachment limit configurable Paul Houssel
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 ` Paul Chaignon [this message]
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=aftonBG4vXaieFLp@mail.gmail.com \
--to=paul.chaignon@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.houssel@orange.com \
--cc=paulhoussel2@gmail.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 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.