On Fri, Feb 20, 2026 at 8:50 PM Tejun Heo <[email protected]> wrote: > > Hello, > > On Fri, Feb 20, 2026 at 07:15:56PM +0200, Amir Goldstein wrote: > ... > > > Adding a comment with the above content would probably be useful. It also > > > might be worthwhile to note that fanotify recursive monitoring wouldn't > > > work > > > reliably as cgroups can go away while inodes are not attached. > > > > Sigh.. it's a shame to grow more weird semantics. > > Yeah, I mean, kernfs *is* weird. > > > But I take this back to the POV of "remote" vs. "local" vfs notifications. > > the IN_DELETE_SELF events added by this change are actually > > "local" vfs notifications. > > > > If we would want to support monitoring cgroups fs super block > > for all added/removed cgroups with fanotify, we would be able > > to implement this as "remote" notifications and in this case, adding > > explicit fsnotify() calls could make sense. > > 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 ;) What are delegation boundaries and NFS boundaries in this context? > 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. But FAN_MNT_ATTACH reports a mountid. Is there a mountid to report on cgroup create? Probably not? Thanks, Amir.
