Hello, Amir. On Fri, Feb 20, 2026 at 10:11:15PM +0200, Amir Goldstein wrote: > > Yeah, that can be useful. For cgroupfs, there would probably need to be a > > way to scope it so that it can be used on delegation boundaries too (which > > we can require to coincide with cgroup NS boundaries). > > I have no idea what the above means. > I could ask Gemini or you and I prefer the latter ;)
Ah, you chose wrong. :) > What are delegation boundaries and NFS boundaries in this context? cgroup delegation is giving control of a subtree to someone else: https://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git/tree/Documentation/admin-guide/cgroup-v2.rst#n537 There's an old way of doing it by changing perms on some files and new way using cgroup namespace. > > Would it be possible to make FAN_MNT_ATTACH work for that? > > FAN_MNT_ATTACH is an event generated on a mntns object. > If "cgroup NS boundaries" is referring to a mntns object and if > this object is available in the context of cgroup create/destroy > then it should be possible. Great, yes, cgroup namespace way should work then. > But FAN_MNT_ATTACH reports a mountid. Is there a mountid > to report on cgroup create? Probably not? Sorry, I thought that was per-mount recursive file event monitoring. FAN_MARK_MOUNT looks like the right thing if we want to allow monitoring cgroup creations / destructions in a subtree without recursively watching each cgroup. Thanks. -- tejun
