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: <ace5c0e3-84fe-469a-babd-4e460ba074dd@huaweicloud.com>
Date: Fri, 30 Jan 2026 08:41:29 +0800
From: Chen Ridong <chenridong@...weicloud.com>
To: Waiman Long <llong@...hat.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 2026/1/30 2:33, Waiman Long wrote:
> 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

Thanks, Longman,

Now that dmem has been added, I believe a new subsystem for GPU scheduling will
be introduced soon.

> 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>
> 
> 

-- 
Best regards,
Ridong