Re: [PATCH v2 1/2] bpf: render CGROUP_LSM_NUM configurable as a KConfig

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Setting `CONFIG_CGROUP_LSM_NUM` to large values (e.g., 300) causes a stack frame size violation in `cgroup_bpf_inherit()`, breaking the build and risking stack overflows.
- [High] Increasing `CONFIG_CGROUP_LSM_NUM` massively bloats `struct cgroup` for every cgroup instance system-wide, causing severe un-reclaimable memory overhead.
- [Low] Setting `CONFIG_CGROUP_LSM_NUM` to 0 creates a global zero-length array.
--

commit 51a90971268ad1dbaa85eb0becb17cac4d98af78
Author: Paul Houssel <paulhoussel2@gmail.com>

bpf: render CGROUP_LSM_NUM configurable as a KConfig

This commit introduces the CONFIG_CGROUP_LSM_NUM Kconfig option to allow
configuring the maximum number of simultaneously attachable BPF_PROG_TYPE_LSM
programs per cgroup. It replaces the hardcoded limit of 10 with a
configurable range from 0 to 300.

> diff --git a/kernel/bpf/Kconfig b/kernel/bpf/Kconfig
> index eb3de35734f09..7f51598aa8fe6 100644
> --- a/kernel/bpf/Kconfig
> +++ b/kernel/bpf/Kconfig
[ ... ]
> @@ -101,4 +101,17 @@ config BPF_LSM
>  
>  	  If you are unsure how to answer this question, answer N.
>  
> +config CGROUP_LSM_NUM
> +	int "Maximum number of per-cgroup LSM hooks"
> +	depends on BPF_LSM
> +	depends on CGROUP_BPF
> +	range 0 300

Could this large upper bound cause a stack frame size violation?

In kernel/bpf/cgroup.c, cgroup_bpf_inherit() allocates an array of pointers
on the stack:

    struct bpf_prog_array *arrays[ARRAY_SIZE(cgrp->bpf.effective)];

The size of the effective array scales directly with MAX_CGROUP_BPF_ATTACH_TYPE.
If CONFIG_CGROUP_LSM_NUM is configured to its maximum of 300,
MAX_CGROUP_BPF_ATTACH_TYPE becomes 329. Allocating 329 pointers on the stack
requires 2,632 bytes, which exceeds the standard kernel stack frame warning
threshold (CONFIG_FRAME_WARN=2048).

Does this large upper bound also bloat struct cgroup for every cgroup
instance system-wide?

MAX_CGROUP_BPF_ATTACH_TYPE dictates the size of four arrays embedded directly
inside struct cgroup_bpf: effective (pointers), progs (hlist_heads),
flags (u8), and revisions (u32).

Increasing the limit from the default 10 to 300 adds over 6KB of memory overhead
to struct cgroup_bpf. Because struct cgroup_bpf is embedded within
struct cgroup, this results in >6KB of un-reclaimable slab memory bloat for
every single cgroup created system-wide.

Could a minimum value of 0 create a global zero-length array?

If set to 0, the declaration in kernel/bpf/cgroup.c expands to:

    static struct cgroup_lsm_atype cgroup_lsm_atype[0];

While GCC supports zero-length arrays as an extension, declaring a static
global zero-length array is non-standard C and can trigger warnings in
fortified builds or with stricter compiler flags.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260506131257.713895-1-paulhoussel2@gmail.com?part=1