[PATCH 0/4] Followups to controllers' v1 compilation

[PATCH 0/4] Followups to controllers' v1 compilation

[Michal Koutný]

The group of patches builds upon recent dissection of memory and cpuset
controller v1 code to under a separate configuration option. The goal of
them patches is to produce behavior that appears to v1 controlelr users
same like if the controller wasn't compiled at all (and no change to v2
users).
Plus there are two preceding patches with cleanups I came across when
looking at the new code.

Michal Koutný (4):
  memcg: Cleanup with !CONFIG_MEMCG_V1
  cgroup/cpuset: Expose cpuset filesystem with cpuset v1 only
  cgroup: Disallow mounting v1 hierarchies without controller
    implementation
  cgroup: Do not report unavailable v1 controllers in /proc/cgroups

 kernel/cgroup/cgroup-v1.c | 17 ++++++++++++++---
 kernel/cgroup/cgroup.c    |  4 ++--
 mm/memcontrol-v1.h        |  2 --
 3 files changed, 16 insertions(+), 7 deletions(-)


base-commit: 8c7e22fc917a0d76794ebf3fcd81f9d91cee4f5d
-- 
2.46.0

[PATCH 1/4] memcg: Cleanup with !CONFIG_MEMCG_V1

[Michal Koutný]

Extern declarations have no definitions with !CONFIG_MEMCG_V1 and no
users, drop them altogether.

Signed-off-by: Michal Koutný <mkoutny@suse.com>
---
 mm/memcontrol-v1.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/mm/memcontrol-v1.h b/mm/memcontrol-v1.h
index 56d7eaa982741..db2ebf8bea6c5 100644
--- a/mm/memcontrol-v1.h
+++ b/mm/memcontrol-v1.h
@@ -140,8 +140,6 @@ static inline bool memcg1_charge_skmem(struct mem_cgroup *memcg, unsigned int nr
 				       gfp_t gfp_mask) { return true; }
 static inline void memcg1_uncharge_skmem(struct mem_cgroup *memcg, unsigned int nr_pages) {}
 
-extern struct cftype memsw_files[];
-extern struct cftype mem_cgroup_legacy_files[];
 #endif	/* CONFIG_MEMCG_V1 */
 
 #endif	/* __MM_MEMCONTROL_V1_H */
-- 
2.46.0

Re: [PATCH 1/4] memcg: Cleanup with !CONFIG_MEMCG_V1

[Shakeel Butt]

On Mon, Sep 09, 2024 at 06:32:20PM GMT, Michal Koutný wrote:
> Extern declarations have no definitions with !CONFIG_MEMCG_V1 and no
> users, drop them altogether.
> 
> Signed-off-by: Michal Koutný <mkoutny@suse.com>

Acked-by: Shakeel Butt <shakeel.butt@linux.dev>

Re: [PATCH 1/4] memcg: Cleanup with !CONFIG_MEMCG_V1

[Tejun Heo]

On Mon, Sep 09, 2024 at 06:32:20PM +0200, Michal Koutný wrote:
> Extern declarations have no definitions with !CONFIG_MEMCG_V1 and no
> users, drop them altogether.
> 
> Signed-off-by: Michal Koutný <mkoutny@suse.com>

Acked-by: Tejun Heo <tj@kernel.org>

This one should go through -mm. If Andrew doesn't pick it up from this
thread, it might be better to repost it.

Thanks.

-- 
tejun

Re: [PATCH 1/4] memcg: Cleanup with !CONFIG_MEMCG_V1

[Andrew Morton]

On Tue, 10 Sep 2024 10:05:57 -1000 Tejun Heo <tj@kernel.org> wrote:

> On Mon, Sep 09, 2024 at 06:32:20PM +0200, Michal Koutný wrote:
> > Extern declarations have no definitions with !CONFIG_MEMCG_V1 and no
> > users, drop them altogether.
> > 
> > Signed-off-by: Michal Koutný <mkoutny@suse.com>
> 
> Acked-by: Tejun Heo <tj@kernel.org>
> 
> This one should go through -mm. If Andrew doesn't pick it up from this
> thread, it might be better to repost it.
> 

Yep, thanks, I grabbed all four patches.

Re: [PATCH 1/4] memcg: Cleanup with !CONFIG_MEMCG_V1

[Tejun Heo]

On Tue, Sep 10, 2024 at 01:19:00PM -0700, Andrew Morton wrote:
> On Tue, 10 Sep 2024 10:05:57 -1000 Tejun Heo <tj@kernel.org> wrote:
> 
> > On Mon, Sep 09, 2024 at 06:32:20PM +0200, Michal Koutný wrote:
> > > Extern declarations have no definitions with !CONFIG_MEMCG_V1 and no
> > > users, drop them altogether.
> > > 
> > > Signed-off-by: Michal Koutný <mkoutny@suse.com>
> > 
> > Acked-by: Tejun Heo <tj@kernel.org>
> > 
> > This one should go through -mm. If Andrew doesn't pick it up from this
> > thread, it might be better to repost it.
> > 
> 
> Yep, thanks, I grabbed all four patches.

Oh, I applied the latter three to the cgroup tree. Should be easy to figure
out later.

Thanks.

-- 
tejun

[PATCH 2/4] cgroup/cpuset: Expose cpuset filesystem with cpuset v1 only

[Michal Koutný]

The cpuset filesystem is a legacy interface to cpuset controller with
(pre-)v1 features. It makes little sense to co-mount it on systems
without cpuset v1, so do no build it when cpuset v1 is not built
neither.

Signed-off-by: Michal Koutný <mkoutny@suse.com>
---
 kernel/cgroup/cgroup.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index c72e18ffbfd82..90e50d6d3cf39 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -2331,7 +2331,7 @@ static struct file_system_type cgroup2_fs_type = {
 	.fs_flags		= FS_USERNS_MOUNT,
 };
 
-#ifdef CONFIG_CPUSETS
+#ifdef CONFIG_CPUSETS_V1
 static const struct fs_context_operations cpuset_fs_context_ops = {
 	.get_tree	= cgroup1_get_tree,
 	.free		= cgroup_fs_context_free,
@@ -6236,7 +6236,7 @@ int __init cgroup_init(void)
 	WARN_ON(register_filesystem(&cgroup_fs_type));
 	WARN_ON(register_filesystem(&cgroup2_fs_type));
 	WARN_ON(!proc_create_single("cgroups", 0, NULL, proc_cgroupstats_show));
-#ifdef CONFIG_CPUSETS
+#ifdef CONFIG_CPUSETS_V1
 	WARN_ON(register_filesystem(&cpuset_fs_type));
 #endif
 
-- 
2.46.0

Re: [PATCH 2/4] cgroup/cpuset: Expose cpuset filesystem with cpuset v1 only

[Waiman Long]

On 9/9/24 12:32, Michal Koutný wrote:
> The cpuset filesystem is a legacy interface to cpuset controller with
> (pre-)v1 features. It makes little sense to co-mount it on systems
> without cpuset v1, so do no build it when cpuset v1 is not built
> neither.
>
> Signed-off-by: Michal Koutný <mkoutny@suse.com>
> ---
>   kernel/cgroup/cgroup.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
> index c72e18ffbfd82..90e50d6d3cf39 100644
> --- a/kernel/cgroup/cgroup.c
> +++ b/kernel/cgroup/cgroup.c
> @@ -2331,7 +2331,7 @@ static struct file_system_type cgroup2_fs_type = {
>   	.fs_flags		= FS_USERNS_MOUNT,
>   };
>   
> -#ifdef CONFIG_CPUSETS
> +#ifdef CONFIG_CPUSETS_V1
>   static const struct fs_context_operations cpuset_fs_context_ops = {
>   	.get_tree	= cgroup1_get_tree,
>   	.free		= cgroup_fs_context_free,
> @@ -6236,7 +6236,7 @@ int __init cgroup_init(void)
>   	WARN_ON(register_filesystem(&cgroup_fs_type));
>   	WARN_ON(register_filesystem(&cgroup2_fs_type));
>   	WARN_ON(!proc_create_single("cgroups", 0, NULL, proc_cgroupstats_show));
> -#ifdef CONFIG_CPUSETS
> +#ifdef CONFIG_CPUSETS_V1
>   	WARN_ON(register_filesystem(&cpuset_fs_type));
>   #endif
>   
Reviewed-by: Waiman Long <longman@redhat.com>

Re: [PATCH 2/4] cgroup/cpuset: Expose cpuset filesystem with cpuset v1 only

[Tejun Heo]

On Mon, Sep 09, 2024 at 06:32:21PM +0200, Michal Koutný wrote:
> The cpuset filesystem is a legacy interface to cpuset controller with
> (pre-)v1 features. It makes little sense to co-mount it on systems
> without cpuset v1, so do no build it when cpuset v1 is not built
> neither.
> 
> Signed-off-by: Michal Koutný <mkoutny@suse.com>

Applied to cgroup/for-6.12 w/ a typo fix and Waiman's reviewed-by added.

Thanks.

-- 
tejun

[PATCH 3/4] cgroup: Disallow mounting v1 hierarchies without controller implementation

[Michal Koutný]

The configs that disable some v1 controllers would still allow mounting
them but with no controller-specific files. (Making such hierarchies
equivalent to named v1 hierarchies.) To achieve behavior consistent with
actual out-compilation of a whole controller, the mounts should treat
respective controllers as non-existent.

Wrap implementation into a helper function, leverage legacy_files to
detect compiled out controllers. The effect is that mounts on v1 would
fail and produce a message like:
  [ 1543.999081] cgroup: Unknown subsys name 'memory'

Signed-off-by: Michal Koutný <mkoutny@suse.com>
---
 kernel/cgroup/cgroup-v1.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
index b9dbf6bf2779d..784337694a4be 100644
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -46,6 +46,12 @@ bool cgroup1_ssid_disabled(int ssid)
 	return cgroup_no_v1_mask & (1 << ssid);
 }
 
+static bool cgroup1_subsys_absent(struct cgroup_subsys *ss)
+{
+	/* Check also dfl_cftypes for file-less controllers, i.e. perf_event */
+	return ss->legacy_cftypes == NULL && ss->dfl_cftypes;
+}
+
 /**
  * cgroup_attach_task_all - attach task 'tsk' to all cgroups of task 'from'
  * @from: attach to all cgroups of a given task
@@ -932,7 +938,8 @@ int cgroup1_parse_param(struct fs_context *fc, struct fs_parameter *param)
 		if (ret != -ENOPARAM)
 			return ret;
 		for_each_subsys(ss, i) {
-			if (strcmp(param->key, ss->legacy_name))
+			if (strcmp(param->key, ss->legacy_name) ||
+			    cgroup1_subsys_absent(ss))
 				continue;
 			if (!cgroup_ssid_enabled(i) || cgroup1_ssid_disabled(i))
 				return invalfc(fc, "Disabled controller '%s'",
@@ -1024,7 +1031,8 @@ static int check_cgroupfs_options(struct fs_context *fc)
 	mask = ~((u16)1 << cpuset_cgrp_id);
 #endif
 	for_each_subsys(ss, i)
-		if (cgroup_ssid_enabled(i) && !cgroup1_ssid_disabled(i))
+		if (cgroup_ssid_enabled(i) && !cgroup1_ssid_disabled(i) &&
+		    !cgroup1_subsys_absent(ss))
 			enabled |= 1 << i;
 
 	ctx->subsys_mask &= enabled;
-- 
2.46.0

Re: [PATCH 3/4] cgroup: Disallow mounting v1 hierarchies without controller implementation

[Tejun Heo]

On Mon, Sep 09, 2024 at 06:32:22PM +0200, Michal Koutný wrote:
> The configs that disable some v1 controllers would still allow mounting
> them but with no controller-specific files. (Making such hierarchies
> equivalent to named v1 hierarchies.) To achieve behavior consistent with
> actual out-compilation of a whole controller, the mounts should treat
> respective controllers as non-existent.
> 
> Wrap implementation into a helper function, leverage legacy_files to
> detect compiled out controllers. The effect is that mounts on v1 would
> fail and produce a message like:
>   [ 1543.999081] cgroup: Unknown subsys name 'memory'
> 
> Signed-off-by: Michal Koutný <mkoutny@suse.com>

Applied to cgroup/for-6.12.

Thanks.

-- 
tejun

[PATCH 4/4] cgroup: Do not report unavailable v1 controllers in /proc/cgroups

[Michal Koutný]

This is a followup to CONFIG-urability of cpuset and memory controllers
for v1 hierarchies. Make the output in /proc/cgroups reflect that
!CONFIG_CPUSETS_V1 is like !CONFIG_CPUSETS and
!CONFIG_MEMCG_V1 is like !CONFIG_MEMCG.

The intended effect is that hiding the unavailable controllers will hint
users not to try mounting them on v1.

Signed-off-by: Michal Koutný <mkoutny@suse.com>
---
 kernel/cgroup/cgroup-v1.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
index 784337694a4be..e28d5f0d20ed0 100644
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -681,11 +681,14 @@ int proc_cgroupstats_show(struct seq_file *m, void *v)
 	 * cgroup_mutex contention.
 	 */
 
-	for_each_subsys(ss, i)
+	for_each_subsys(ss, i) {
+		if (cgroup1_subsys_absent(ss))
+			continue;
 		seq_printf(m, "%s\t%d\t%d\t%d\n",
 			   ss->legacy_name, ss->root->hierarchy_id,
 			   atomic_read(&ss->root->nr_cgrps),
 			   cgroup_ssid_enabled(i));
+	}
 
 	return 0;
 }
-- 
2.46.0

Re: [PATCH 4/4] cgroup: Do not report unavailable v1 controllers in /proc/cgroups

[Waiman Long]

On 9/9/24 12:32, Michal Koutný wrote:
> This is a followup to CONFIG-urability of cpuset and memory controllers
> for v1 hierarchies. Make the output in /proc/cgroups reflect that
> !CONFIG_CPUSETS_V1 is like !CONFIG_CPUSETS and
> !CONFIG_MEMCG_V1 is like !CONFIG_MEMCG.
>
> The intended effect is that hiding the unavailable controllers will hint
> users not to try mounting them on v1.
>
> Signed-off-by: Michal Koutný <mkoutny@suse.com>
> ---
>   kernel/cgroup/cgroup-v1.c | 5 ++++-
>   1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
> index 784337694a4be..e28d5f0d20ed0 100644
> --- a/kernel/cgroup/cgroup-v1.c
> +++ b/kernel/cgroup/cgroup-v1.c
> @@ -681,11 +681,14 @@ int proc_cgroupstats_show(struct seq_file *m, void *v)
>   	 * cgroup_mutex contention.
>   	 */
>   
> -	for_each_subsys(ss, i)
> +	for_each_subsys(ss, i) {
> +		if (cgroup1_subsys_absent(ss))
> +			continue;
>   		seq_printf(m, "%s\t%d\t%d\t%d\n",
>   			   ss->legacy_name, ss->root->hierarchy_id,
>   			   atomic_read(&ss->root->nr_cgrps),
>   			   cgroup_ssid_enabled(i));
> +	}
>   
>   	return 0;
>   }
Reviewed-by: Waiman Long <longman@redhat.com>

Re: [PATCH 4/4] cgroup: Do not report unavailable v1 controllers in /proc/cgroups

[Tejun Heo]

On Mon, Sep 09, 2024 at 06:32:23PM +0200, Michal Koutný wrote:
> This is a followup to CONFIG-urability of cpuset and memory controllers
> for v1 hierarchies. Make the output in /proc/cgroups reflect that
> !CONFIG_CPUSETS_V1 is like !CONFIG_CPUSETS and
> !CONFIG_MEMCG_V1 is like !CONFIG_MEMCG.
> 
> The intended effect is that hiding the unavailable controllers will hint
> users not to try mounting them on v1.
> 
> Signed-off-by: Michal Koutný <mkoutny@suse.com>

Applied to cgroup/for-6.12 w/ Waiman's reviewed-by.

Thanks.

-- 
tejun

Re: [PATCH 4/4] cgroup: Do not report unavailable v1 controllers in /proc/cgroups

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]

On Mon, 2024-09-09 at 18:32 +0200, Michal Koutný wrote:
> This is a followup to CONFIG-urability of cpuset and memory controllers
> for v1 hierarchies. Make the output in /proc/cgroups reflect that
> !CONFIG_CPUSETS_V1 is like !CONFIG_CPUSETS and
> !CONFIG_MEMCG_V1 is like !CONFIG_MEMCG.
> 
> The intended effect is that hiding the unavailable controllers will hint
> users not to try mounting them on v1.

This change can cause problems for the OpenJDK JVM, as reported in
<https://bugs.debian.org/1108294>.

Since OpenJDK version 11, the JVM can detect and adapt to cpuset and
memory limits.  It supports both the cgroups v1 and v2 API, but before
version 25 it always relied on /proc/cgroups to detect whether those
controllers were enabled.

The result of this patch is that if CONFIG_MEMCG_V1 is disabled the JVM
can easily trigger OOM when otherwise it would trim its memory usage
through garbage collection.  (For cpusets, I'm not sure of the impact
but I think it might make bad decisions about the size of thread pools.)

Although the fix in OpenJDK 25 can probably be backported to older
versions, this issue primarily affects container workloads so fixing
this in distribution packages would not be sufficient.

The obvious compatibility fix for this at the kernel level is to enable
CONFIG_{CPUSETS,MEMCG}_V1.  But since the v1 API has long been
deprecated and is not actually needed by OpenJDK, I would prefer not to
do that.

Would you consider reverting this change for the sake of compatibility?

Ben.

> Signed-off-by: Michal Koutný <mkoutny@suse.com>
> ---
>  kernel/cgroup/cgroup-v1.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
> index 784337694a4be..e28d5f0d20ed0 100644
> --- a/kernel/cgroup/cgroup-v1.c
> +++ b/kernel/cgroup/cgroup-v1.c
> @@ -681,11 +681,14 @@ int proc_cgroupstats_show(struct seq_file *m, void *v)
>  	 * cgroup_mutex contention.
>  	 */
>  
> -	for_each_subsys(ss, i)
> +	for_each_subsys(ss, i) {
> +		if (cgroup1_subsys_absent(ss))
> +			continue;
>  		seq_printf(m, "%s\t%d\t%d\t%d\n",
>  			   ss->legacy_name, ss->root->hierarchy_id,
>  			   atomic_read(&ss->root->nr_cgrps),
>  			   cgroup_ssid_enabled(i));
> +	}
>  
>  	return 0;
>  }

-- 
Ben Hutchings
73.46% of all statistics are made up.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 4/4] cgroup: Do not report unavailable v1 controllers in /proc/cgroups

[Michal Koutný]

Hello Ben.

On Wed, Jul 09, 2025 at 08:22:09PM +0200, Ben Hutchings <ben@decadent.org.uk> wrote:
> Would you consider reverting this change for the sake of compatibility?

As you write, it's not fatally broken and it may be "just" an issue of
container images that got no fresh rebuild. (And I think it should be
generally discouraged running containers with stale deps in them.)

The original patch would mainly serve legacy userspace (host) setups on
top of contemporary kernel (besides API purity reasons). Admittedly,
these should be rare and eventually extinct in contrast with your
example where it's a containerized userspace (which typically could do
no cgroup setup) that may still have some user demand.

So, I'd be more confident with the revert if such an adjustment was
carried downstream by some distro and proven its viability first. Do you
know of any in the wild?

I appreciate your report,
Michal

Re: [PATCH 4/4] cgroup: Do not report unavailable v1 controllers in /proc/cgroups

[Tejun Heo]

On Fri, Jul 11, 2025 at 03:10:44PM +0200, Michal Koutný wrote:
> Hello Ben.
> 
> On Wed, Jul 09, 2025 at 08:22:09PM +0200, Ben Hutchings <ben@decadent.org.uk> wrote:
> > Would you consider reverting this change for the sake of compatibility?
> 
> As you write, it's not fatally broken and it may be "just" an issue of
> container images that got no fresh rebuild. (And I think it should be
> generally discouraged running containers with stale deps in them.)
> 
> The original patch would mainly serve legacy userspace (host) setups on
> top of contemporary kernel (besides API purity reasons). Admittedly,
> these should be rare and eventually extinct in contrast with your
> example where it's a containerized userspace (which typically could do
> no cgroup setup) that may still have some user demand.
> 
> So, I'd be more confident with the revert if such an adjustment was
> carried downstream by some distro and proven its viability first. Do you
> know of any in the wild?

I think we still want to deprecate /proc/cgroups but given that there are
impacted users maybe we can bring it back under a boottime param w/ warning?

Thanks.

-- 
tejun

Re: [PATCH 4/4] cgroup: Do not report unavailable v1 controllers in /proc/cgroups

[Michal Koutný]

[-- Attachment #1: Type: text/plain, Size: 4350 bytes --]

On Fri, Jul 11, 2025 at 12:15:07PM -1000, Tejun Heo <tj@kernel.org> wrote:
> I think we still want to deprecate /proc/cgroups but given that there are
> impacted users maybe we can bring it back under a boottime param w/ warning?

Something like below? (I don't change the log level.)

Ben, the affected Java users could modify it at boot time. I saw your
revert is in v6.12, so you may also want backport of a0ab1453226d8 to
give the users a message. (I realize current->comm in the message would
be even more instructive.)

-- >8 --

From ace88e9e3a77ff3fe86aee4b7a5866b3bfd2df58 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Michal=20Koutn=C3=BD?= <mkoutny@suse.com>
Date: Thu, 17 Jul 2025 17:38:47 +0200
Subject: [PATCH] cgroup: Add compatibility option for content of /proc/cgroups
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

/proc/cgroups lists only v1 controllers by default, however, this is
only enforced since the commit af000ce85293b ("cgroup: Do not report
unavailable v1 controllers in /proc/cgroups") and there is software in
the wild that uses content of /proc/cgroups to decide on availability of
v2 (sic) controllers.

Add a boottime param that can bring back the previous behavior for
setups where the check in the software cannot be changed and it causes
e.g. unintended OOMs.

Also, this patch takes out cgrp_v1_visible from cgroup1_subsys_absent()
guard since it's only important to check which hierarchy (v1 vs v2) the
subsys is attached to. This has no effect on the printed message but
the code is cleaner since cgrp_v1_visible is really about mounted
hierarchies, not the content of /proc/cgroups.

Link: https://lore.kernel.org/r/b26b60b7d0d2a5ecfd2f3c45f95f32922ed24686.camel@decadent.org.uk
Fixes: af000ce85293b ("cgroup: Do not report unavailable v1 controllers in /proc/cgroups")
Fixes: a0ab1453226d8 ("cgroup: Print message when /proc/cgroups is read on v2-only system")
Signed-off-by: Michal Koutný <mkoutny@suse.com>
---
 Documentation/admin-guide/kernel-parameters.txt |  8 ++++++++
 kernel/cgroup/cgroup-v1.c                       | 14 ++++++++++++--
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 07e22ba5bfe34..f6d317e1674d6 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -633,6 +633,14 @@
 			named mounts. Specifying both "all" and "named" disables
 			all v1 hierarchies.
 
+	cgroup_v1_proc=	[KNL] Show also missing controllers in /proc/cgroups
+			Format: { "true" | "false" }
+			/proc/cgroups lists only v1 controllers by default.
+			This compatibility option enables listing also v2
+			controllers (whose v1 code is not compiled!), so that
+			semi-legacy software can check this file to decide
+			about usage of v2 (sic) controllers.
+
 	cgroup_favordynmods= [KNL] Enable or Disable favordynmods.
 			Format: { "true" | "false" }
 			Defaults to the value of CONFIG_CGROUP_FAVOR_DYNMODS.
diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
index fa24c032ed6fe..2a4a387f867ab 100644
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -32,6 +32,9 @@ static u16 cgroup_no_v1_mask;
 /* disable named v1 mounts */
 static bool cgroup_no_v1_named;
 
+/* Show unavailable controllers in /proc/cgroups */
+static bool proc_show_all;
+
 /*
  * pidlist destructions need to be flushed on cgroup destruction.  Use a
  * separate workqueue as flush domain.
@@ -683,10 +686,11 @@ int proc_cgroupstats_show(struct seq_file *m, void *v)
 	 */
 
 	for_each_subsys(ss, i) {
-		if (cgroup1_subsys_absent(ss))
-			continue;
 		cgrp_v1_visible |= ss->root != &cgrp_dfl_root;
 
+		if (!proc_show_all && cgroup1_subsys_absent(ss))
+			continue;
+
 		seq_printf(m, "%s\t%d\t%d\t%d\n",
 			   ss->legacy_name, ss->root->hierarchy_id,
 			   atomic_read(&ss->root->nr_cgrps),
@@ -1359,3 +1363,9 @@ static int __init cgroup_no_v1(char *str)
 	return 1;
 }
 __setup("cgroup_no_v1=", cgroup_no_v1);
+
+static int __init cgroup_v1_proc(char *str)
+{
+	return (kstrtobool(str, &proc_show_all) == 0);
+}
+__setup("cgroup_v1_proc=", cgroup_v1_proc);
-- 
2.50.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 4/4] cgroup: Do not report unavailable v1 controllers in /proc/cgroups

[Tejun Heo]

On Fri, Jul 18, 2025 at 11:18:54AM +0200, Michal Koutný wrote:
> From ace88e9e3a77ff3fe86aee4b7a5866b3bfd2df58 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Michal=20Koutn=C3=BD?= <mkoutny@suse.com>
> Date: Thu, 17 Jul 2025 17:38:47 +0200
> Subject: [PATCH] cgroup: Add compatibility option for content of /proc/cgroups
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> /proc/cgroups lists only v1 controllers by default, however, this is
> only enforced since the commit af000ce85293b ("cgroup: Do not report
> unavailable v1 controllers in /proc/cgroups") and there is software in
> the wild that uses content of /proc/cgroups to decide on availability of
> v2 (sic) controllers.
> 
> Add a boottime param that can bring back the previous behavior for
> setups where the check in the software cannot be changed and it causes
> e.g. unintended OOMs.
> 
> Also, this patch takes out cgrp_v1_visible from cgroup1_subsys_absent()
> guard since it's only important to check which hierarchy (v1 vs v2) the
> subsys is attached to. This has no effect on the printed message but
> the code is cleaner since cgrp_v1_visible is really about mounted
> hierarchies, not the content of /proc/cgroups.
> 
> Link: https://lore.kernel.org/r/b26b60b7d0d2a5ecfd2f3c45f95f32922ed24686.camel@decadent.org.uk
> Fixes: af000ce85293b ("cgroup: Do not report unavailable v1 controllers in /proc/cgroups")
> Fixes: a0ab1453226d8 ("cgroup: Print message when /proc/cgroups is read on v2-only system")
> Signed-off-by: Michal Koutný <mkoutny@suse.com>

Applied to cgroup/for-6.17.

Thanks.

-- 
tejun

Re: [PATCH 4/4] cgroup: Do not report unavailable v1 controllers in /proc/cgroups

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]

On Fri, 2025-07-11 at 15:10 +0200, Michal Koutný wrote:
> Hello Ben.
> 
> On Wed, Jul 09, 2025 at 08:22:09PM +0200, Ben Hutchings <ben@decadent.org.uk> wrote:
> > Would you consider reverting this change for the sake of compatibility?
> 
> As you write, it's not fatally broken and it may be "just" an issue of
> container images that got no fresh rebuild. (And I think it should be
> generally discouraged running containers with stale deps in them.)
> 
> The original patch would mainly serve legacy userspace (host) setups on
> top of contemporary kernel (besides API purity reasons). Admittedly,
> these should be rare and eventually extinct in contrast with your
> example where it's a containerized userspace (which typically could do
> no cgroup setup) that may still have some user demand.
> 
> So, I'd be more confident with the revert if such an adjustment was
> carried downstream by some distro and proven its viability first. Do you
> know of any in the wild?

The revert has just gone into Debian unstable, targetting the upcoming
stable release.  So at this point I can't confidently state that it
won't also cause regressions.

Ben.

> 
> I appreciate your report,
> Michal

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment destroyed
                                                    - Carolyn Scheppner

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]