Re: [PATCH v4 2/3] kernfs: Send IN_DELETE_SELF and IN_IGNORED

[Tejun Heo <tj@kernel.org>]

(cc'ing Christian Brauner)

On Sat, Feb 21, 2026 at 06:11:28PM +0200, Amir Goldstein wrote:
> On Sat, Feb 21, 2026 at 12:32 AM Tejun Heo <tj@kernel.org> wrote:
> >
> > 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.
> 
> The problem sounds very similar to subtree monitoring for mkdir/rmdir on
> a filesystem, which is a problem that we have not yet solved.
> 
> The problem with FAN_MARK_MOUNT is that it does not support the
> events CREATE/DELETE, because those events are currently

Ah, bummer.

> monitored in context where the mount is not available and anyway
> what users want to get notified on a deleted file/dir in a subtree
> regardless of the mount through which the create/delete was done.
> 
> Since commit 58f5fbeb367ff ("fanotify: support watching filesystems
> and mounts inside userns") and fnaotify groups can be associated
> with a userns.
> 
> I was thinking that we can have a model where events are delivered
> to a listener based on whether or not the uid/gid of the object are
> mappable to the userns of the group.

Given how different NSes can be used independently of each other, it'd
probably be cleaner if it doesn't have to depend on another NS.

> In a filesystem, this criteria cannot guarantee the subtree isolation.
> I imagine that for delegated cgroups this criteria could match what
> you need, but I am basing this on pure speculation.

There's a lot of flexibility in the mechanism, so it's difficult to tell.
e.g. There's nothing preventing somebody from creating two separate subtrees
delegated to the same user.

Christian was mentioning allowing separate super for different cgroup mounts
in another thread. cc'ing him for context.

Thanks.

-- 
tejun