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

[Christian Brauner <brauner@kernel.org>]

On Tue, Mar 03, 2026 at 03:27:52PM +0100, Amir Goldstein wrote:
> On Tue, Feb 24, 2026 at 12:03 PM Christian Brauner <brauner@kernel.org> wrote:
> >
> > On Mon, Feb 23, 2026 at 06:27:31AM -1000, Tejun Heo wrote:
> > > (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.
> >
> > Delegation is based on inode ownership I'm not sure how well this will
> > fit into the fanotify model. Maybe the group logic for userns that
> > fanotify added works. I'm not super sure.
> >
> > > Christian was mentioning allowing separate super for different cgroup mounts
> > > in another thread. cc'ing him for context.
> >
> > If cgroupfs changes to tmpfs semantics where each mount gives you a new
> > superblock then it's possible to give each container its own superblock.
> > That in turn would make it possible to place fanotify watches on the
> > superblock itself. I think you'd roughly need something like the
> > following permission model:
> >
> 
> It's hard for me to estimate the effort of changing to multi sb model,
> but judging by the length of the email I trimmed below, it does not
> sound trivial...
> 
> How do you guys feel about something like this patch which associates
> an owner userns to every cgroup?
> 
> I have this POC branch from a long time ago [1] to filter all events
> on sb by in_userns() criteria.  The semantics for real filesystems
> were a bit difficult, but perhaps this model can work well for these
> pseudo singleton fs.
> 
> I am trying to work on a model that could be useful for both cgroupfs
> and nsfs:
> 
> If user is capable in userns, user will be able to set an sb
> watch for all events (say DELETE_SELF) on the sb, for objects
> whose owner_userns is in_userns() of the fanotify listener.
> 
> This will enable watching for torn down cgroups and namepsaces
> which are visible to said user via delegated cgroups mount
> or via listns().
> 
> I would like to allow calling fsnotify_obj_remove() hook with
> encoded object fid (e.g. nsfs_file_handle) instead of the vfs inode,
> so that cgroupfs/nsfs could report dying objects without needing
> to associate a vfs inode with them.
> 
> WDYT? Is this an interesting direction to persure?

I'd need to see the patches. I barely remember the details tbh.
It doesn't sound crazy though.