Re: Question on damon_sysfs_memcg_path_to_id() path resolution
SJ Park <[email protected]>
| Newsgroups | dev.linux.lists.damon |
|---|---|
| Message-ID | <[email protected]> |
On Sat, 18 Jul 2026 16:40:51 +0800 Song Hu <[email protected]> wrote: > Hi, > > Sorry for the late reply. No worry! [...] > > I find the current behavior might be tedious if the user runs DAMON inside > > cgroups. Finding the absolute cgroup path inside containers might be > > challenging. If that's the case, I'm up to change or extend the behaviors. > > > > If this is only for making the code easier to maintain, I don't really feel > > like it deserves the behavioral changes, to be honest. > I looked into the container case more carefully and I'm no longer sure > it justifies the change. > > DAMON sysfs is root-only (state is 0600 under /sys/kernel/mm/damon), so > whoever configures a scheme is effectively a host-level operator. That > operator can obtain the absolute cgroup path directly (e.g. from > /proc/<pid>/cgroup), and the usage docs already show host-absolute > paths. A process able to write host DAMON sysfs from inside a non-init > cgroup namespace is a privileged host-admin case, not really a "DAMON > inside a container" user. So I think the namespace-relative benefit is > marginal at best. > > Given that, and your point that maintainability alone isn't worth a > behavioral change, I'll leave damon_sysfs_memcg_path_to_id() as-is. Makes sense. > > Thanks for thinking it through with me -- and for the cgroup_get_from_path pointer. You're welcome. I liked this dicsussion. Looking forward to the next one! Thanks, SJ [...]