linux-kernel - Re: [PATCH 0/8] memcg: separate private and public ID namespaces

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: <20251226181737.254305-1-sj@kernel.org>
Date: Fri, 26 Dec 2025 10:17:36 -0800
From: SeongJae Park <sj@...nel.org>
To: Shakeel Butt <shakeel.butt@...ux.dev>
Cc: SeongJae Park <sj@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Johannes Weiner <hannes@...xchg.org>,
	Michal Hocko <mhocko@...nel.org>,
	Roman Gushchin <roman.gushchin@...ux.dev>,
	Muchun Song <muchun.song@...ux.dev>,
	Meta kernel team <kernel-team@...a.com>,
	linux-mm@...ck.org,
	cgroups@...r.kernel.org,
	damon@...ts.linux.dev,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/8] memcg: separate private and public ID namespaces

On Thu, 25 Dec 2025 15:21:08 -0800 Shakeel Butt <shakeel.butt@...ux.dev> wrote:

> The memory cgroup subsystem maintains a private ID infrastructure that
> is decoupled from the cgroup IDs. This private ID system exists because
> some kernel objects (like swap entries and shadow entries in the
> workingset code) can outlive the cgroup they were associated with.
> The motivation is best described in commit 73f576c04b941 ("mm:
> memcontrol: fix cgroup creation failure after many small jobs").
> 
> Unfortunately, some in-kernel users (DAMON, LRU gen debugfs interface,
> shrinker debugfs) started exposing these private IDs to userspace.

Technically speaking, DAMON is not exposing the private IDs to userspace.  It
does use the ids to specify the memory cgroups in kernel space.  But, when it
communicates with the user space, it uses the paths of the cgroups, not the
ids.

> This is problematic because:
> 
> 1. The private IDs are internal implementation details that could change
> 2. Userspace already has access to cgroup IDs through the cgroup
>    filesystem
> 3. Using different ID namespaces in different interfaces is confusing

Though DAMON is not exposing the IDs to the userspace, I agree it is better to
use public id, mainly because DAMON doesn't really care about the
cgroup-outlive objects.  Also, it would allow easier change of the
implementation details and make more consistent kernel-space API usages.


Thanks,
SJ

[...]