linux-kernel - Re: [PATCH -next] cgroup: increase maximum subsystem count from 16 to 32

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6fc1fb93-7010-4381-a9a9-68a9b81acf88@redhat.com>
Date: Thu, 29 Jan 2026 13:33:56 -0500
From: Waiman Long <llong@...hat.com>
To: Chen Ridong <chenridong@...weicloud.com>, Michal Koutný
 <mkoutny@...e.com>
Cc: tj@...nel.org, hannes@...xchg.org, rostedt@...dmis.org,
 mhiramat@...nel.org, mathieu.desnoyers@...icios.com, inwardvessel@...il.com,
 shakeel.butt@...ux.dev, cgroups@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
 lujialin4@...wei.com
Subject: Re: [PATCH -next] cgroup: increase maximum subsystem count from 16 to
 32

On 1/29/26 4:51 AM, Chen Ridong wrote:
>
> On 2026/1/29 17:23, Michal Koutný wrote:
>> On Thu, Jan 29, 2026 at 06:31:33AM +0000, Chen Ridong <chenridong@...weicloud.com> wrote:
>>> From: Chen Ridong <chenridong@...wei.com>
>>>
>>> The current cgroup subsystem limit of 16 is insufficient, as the number of
>>> subsystems has already reached this maximum.
>> Indeed. But some of them are legacy (and some novel). Do you really need
>> one kernel image with every subsys config enabled?
>>
> We compiled with 'make allmodconfig'.
>
>>> Attempting to add new subsystems beyond this limit results in boot
>>> failures.
>> That sounds like BUILD_BUG_ON(CGROUP_SUBSYS_COUNT > 16) doesn't trigger
>> during build for you. Is the macro broken?
>>
> The BUILD_BUG_ON(CGROUP_SUBSYS_COUNT > 16) macro worked correctly. However, I
> only modified the code to allow compilation to pass, and the system subsequently
> failed to boot.
>
>>> This patch increases the maximum number of supported cgroup subsystems from
>>> 16 to 32, providing adequate headroom for future subsystem additions.
>> It may be needed one day but I'd suggest binding this change with
>> introduction of actual new controller.
>> (As we have some CONFIG_*_V1 options that default to N, I'm thinking
>> about switching config's default to N as well (like:
>> CONFIG_CGROUP_CPUACCT CONFIG_CGROUP_DEVICE CONFIG_CGROUP_FREEZER
>> CONFIG_CGROUP_DEBGU), arch/x86/configs/x86_64_defconfig is not exactly
>> pinnacle of freshness :-/)
>>
>>
> Can I propose increasing the maximum number now? If we switch certain configs to
> default N and then a new subsystem is added later, the default configuration may
> work fine, but it will become a problem under allmodconfig — which some users
> actually rely on.
>
> Besides, this shouldn't be a major change, right?

Yes, I agreed that it is not a major change. I count the number of 
SUBSYS() in include/linux/cgroup_subsys.h and there are exactly 16 of 
them. So introduction of a new cgroup subsystem will break the current 
limit. I remember that there was talk about adding scheduling cgroup on 
the GPU side. One day, a new cgroup subsystem may be added without the 
awareness that the subsystem limit has to be extended causing issue down 
the line. So I support the idea of extending it now so that there is one 
less thing to worry about when a new cgroup subsystem is added in the 
future.

Acked-by: Waiman Long <longman@...hat.com>