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

[Paul Chaignon <paul.chaignon@gmail.com>]

On Wed, May 06, 2026 at 03:52:37PM +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/include/linux/bpf-cgroup-defs.h b/include/linux/bpf-cgroup-defs.h
> > index c9e6b26abab6..9ab5ca3dbaba 100644
> > --- a/include/linux/bpf-cgroup-defs.h
> > +++ b/include/linux/bpf-cgroup-defs.h
> > @@ -12,7 +12,7 @@ struct bpf_prog_array;
> >
> >  #ifdef CONFIG_BPF_LSM
> >  /* Maximum number of concurrently attachable per-cgroup LSM hooks. */
> > -#define CGROUP_LSM_NUM 10
> > +#define CGROUP_LSM_NUM CONFIG_CGROUP_LSM_NUM
> >  #else
> >  #define CGROUP_LSM_NUM 0
> >  #endif
> 
> [ ... ]
> 
> > diff --git a/kernel/bpf/Kconfig b/kernel/bpf/Kconfig
> > index eb3de35734f0..050af0b72651 100644
> > --- a/kernel/bpf/Kconfig
> > +++ b/kernel/bpf/Kconfig
> > @@ -101,4 +101,23 @@ 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
>               ^^^
> 
> Should the minimum range be 1 instead of 0? When CONFIG_CGROUP_LSM_NUM=0,
> the enum in include/linux/bpf-cgroup-defs.h calculates:

That makes sense to me, especially since we already have CONFIG_BPF_LSM
to disable BPF LSM altogether. CONFIG_CGROUP_LSM_NUM=0 could be useful
if we wanted to offer a way to disable per-cgroup LSM specifically, but
then you'd need to rework things a bit as pointed out by the bot. I'm
not sure it's worth it.

> 
> enum cgroup_bpf_attach_type {
>     ...
>     CGROUP_LSM_START,
>     CGROUP_LSM_END = CGROUP_LSM_START + CGROUP_LSM_NUM - 1,
>     ...
> };
> 
> This results in CGROUP_LSM_END being less than CGROUP_LSM_START (END =
> START - 1), which contradicts C enum range conventions. While the runtime
> behavior stays safe since bpf_cgroup_atype_find returns -E2BIG for empty
> arrays, the enum definition is semantically incorrect.
> 
> The Kconfig help text refers to "Maximum number of concurrently attachable
> per-cgroup LSM hooks" which suggests at least one hook should be
> attachable.
> 
> > +	default 10
> > +	help
> > +	  Maximum number of concurrently attachable per-cgroup LSM hooks.
> > +	  Increasing this value has two memory costs:
> > +		- 8 bytes per added hook (due to growing
> > +		cgroup_lsm_atype[] array in kernel/bpf/cgroup.c)
> > +
> > +		- 25 bytes per added hook, because each hook adds a value to
> > +		MAX_CGROUP_BPF_ATTACH_TYPE and thus increases the
> > +		effective, progs, flags and revisions arrays in struct
> > +		cgroup_bpf
> > +
> > +	  If you are unsure, leave the default value.
> > +
> >  endmenu # "BPF subsystem"
> 
> 
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
> 
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/25444641622