On Tue, Feb 17, 2026 at 2:19 AM Amir Goldstein <[email protected]> wrote: > > On Thu, Feb 12, 2026 at 01:58:13PM -0800, T.J. Mercier wrote: > > Currently some kernfs files (e.g. cgroup.events, memory.events) support > > inotify watches for IN_MODIFY, but unlike with regular filesystems, they > > do not receive IN_DELETE_SELF or IN_IGNORED events when they are > > removed. > > > > This creates a problem for processes monitoring cgroups. For example, a > > service monitoring memory.events for memory.high breaches needs to know > > when a cgroup is removed to clean up its state. Where it's known that a > > cgroup is removed when all processes die, without IN_DELETE_SELF the > > service must resort to inefficient workarounds such as: > > 1. Periodically scanning procfs to detect process death (wastes CPU and > > is susceptible to PID reuse). > > 2. Placing an additional IN_DELETE watch on the parent directory > > (wastes resources managing double the watches). > > 3. Holding a pidfd for every monitored cgroup (can exhaust file > > descriptors). > > > > This patch enables kernfs to send IN_DELETE_SELF and IN_IGNORED events. > > This allows applications to rely on a single existing watch on the file > > of interest (e.g. memory.events) to receive notifications for both > > modifications and the eventual removal of the file, as well as automatic > > watch descriptor cleanup, simplifying userspace logic and improving > > resource efficiency. > > This looks very useful, > But, > How will the application know that ti can rely on IN_DELETE_SELF > from cgroups if this is not an opt-in feature? > > Essentially, this is similar to the discussions on adding "remote" > fs notification support (e.g. for smb) and in those discussions > I insist that "remote" notification should be opt-in (which is > easy to do with an fanotify init flag) and I claim that mixing > "remote" events with "local" events on the same group is undesired.
I think this situation is a bit different because this isn't adding new features to fsnotify. This is filling a gap that you'd expect to work if you only read the cgroups or inotify documentation without realizing that kernfs is simply wired up differently for notification support than most other filesystems, and only partially supports the existing notification events. It's opt-in in the sense that an application registers for IN_DELETE_SELF, but other than a runtime test like what I added in the selftests I'm not sure if there's a good way to detect the kernel will actually send the event. Practically speaking though, if merged upstream I will backport these patches to all the kernels we use so a runtime check shouldn't be necessary for our applications. > However, IN_IGNORED is created when an inotify watch is removed > and IN_DELETE_SELF is called when a vfs inode is destroyed. > When setting an inotify watch for IN_IGNORED|IN_DELETE_SELF there > has to be a vfs inode with inotify mark attached, so why are those > events not created already? What am I missing? The difference is vfs isn't involved when kernfs files are unlinked. When a cgroup removal occurs, we get to kernfs_remove via kernfs' inode_operations without calling vfs_unlink. (You can't rm cgroup files directly.) > Are you expecting to get IN_IGNORED|IN_DELETE_SELF on an entry > while watching the parent? Because this is not how the API works. No, only on the file being watched. The parent should only get IN_DELETE, but I read your feedback below and I'm fine with removing that part and just sending the DELETE_SELF and IN_IGNORED events. > I think it should be possible to set a super block fanotify watch > on cgroupfs and get all the FAN_DELETE_SELF events, but maybe we > do not allow this right now, I did not check - just wanted to give > you another direction to follow. > > > > > Implementation details: > > The kernfs notification worker is updated to handle file deletion. > > fsnotify handles sending MODIFY events to both a watched file and its > > parent, but it does not handle sending a DELETE event to the parent and > > a DELETE_SELF event to the watched file in a single call. Therefore, > > separate fsnotify calls are made: one for the parent (DELETE) and one > > for the child (DELETE_SELF), while retaining the optimized single call > > IN_DELETE_SELF and IN_IGNORED are special and I don't really mind adding > them to kernfs seeing that they are very useful, but adding IN_DELETE > without adding IN_CREATE, that is very arbitrary and I don't like it as > much. That's fair, and the IN_DELETE isn't actually needed for my use case, but I figured I would add the parent notification for file deletions since it is already there for MODIFY events, and I was modifying that area of the code anyway. I'll remove the parent notification for DELETE and just send DELETE_SELF and IGNORED with fsnotify_inoderemove() in V3. > > for MODIFY events. > > > > Signed-off-by: T.J. Mercier <[email protected]> > > --- > > fs/kernfs/dir.c | 21 +++++++++++++++++++++ > > fs/kernfs/file.c | 16 ++++++++++------ > > fs/kernfs/kernfs-internal.h | 3 +++ > > 3 files changed, 34 insertions(+), 6 deletions(-) > > > > diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c > > index 29baeeb97871..e5bda829fcb8 100644 > > --- a/fs/kernfs/dir.c > > +++ b/fs/kernfs/dir.c > > @@ -9,6 +9,7 @@ > > > > #include <linux/sched.h> > > #include <linux/fs.h> > > +#include <linux/fsnotify_backend.h> > > #include <linux/namei.h> > > #include <linux/idr.h> > > #include <linux/slab.h> > > @@ -1471,6 +1472,23 @@ void kernfs_show(struct kernfs_node *kn, bool show) > > up_write(&root->kernfs_rwsem); > > } > > > > +static void kernfs_notify_file_deleted(struct kernfs_node *kn) > > +{ > > + static DECLARE_WORK(kernfs_notify_deleted_work, > > + kernfs_notify_workfn); > > + > > + guard(spinlock_irqsave)(&kernfs_notify_lock); > > + /* may overwite already pending FS_MODIFY events */ > > + kn->attr.notify_event = FS_DELETE; > > + > > + if (!kn->attr.notify_next) { > > + kernfs_get(kn); > > + kn->attr.notify_next = kernfs_notify_list; > > + kernfs_notify_list = kn; > > + schedule_work(&kernfs_notify_deleted_work); > > + } > > +} > > + > > static void __kernfs_remove(struct kernfs_node *kn) > > { > > struct kernfs_node *pos, *parent; > > @@ -1520,6 +1538,9 @@ static void __kernfs_remove(struct kernfs_node *kn) > > struct kernfs_iattrs *ps_iattr = > > parent ? parent->iattr : NULL; > > > > + if (kernfs_type(pos) == KERNFS_FILE) > > + kernfs_notify_file_deleted(pos); > > + > > /* update timestamps on the parent */ > > down_write(&kernfs_root(kn)->kernfs_iattr_rwsem); > > > > diff --git a/fs/kernfs/file.c b/fs/kernfs/file.c > > index e978284ff983..2d21af3cfcad 100644 > > --- a/fs/kernfs/file.c > > +++ b/fs/kernfs/file.c > > @@ -37,8 +37,8 @@ struct kernfs_open_node { > > */ > > #define KERNFS_NOTIFY_EOL ((void *)&kernfs_notify_list) > > > > -static DEFINE_SPINLOCK(kernfs_notify_lock); > > -static struct kernfs_node *kernfs_notify_list = KERNFS_NOTIFY_EOL; > > +DEFINE_SPINLOCK(kernfs_notify_lock); > > +struct kernfs_node *kernfs_notify_list = KERNFS_NOTIFY_EOL; > > > > static inline struct mutex *kernfs_open_file_mutex_ptr(struct kernfs_node > > *kn) > > { > > @@ -909,7 +909,7 @@ static loff_t kernfs_fop_llseek(struct file *file, > > loff_t offset, int whence) > > return ret; > > } > > > > -static void kernfs_notify_workfn(struct work_struct *work) > > +void kernfs_notify_workfn(struct work_struct *work) > > { > > struct kernfs_node *kn; > > struct kernfs_super_info *info; > > @@ -959,15 +959,19 @@ static void kernfs_notify_workfn(struct work_struct > > *work) > > if (p_inode) { > > fsnotify(notify_event | FS_EVENT_ON_CHILD, > > inode, FSNOTIFY_EVENT_INODE, > > - p_inode, &name, inode, 0); > > + p_inode, &name, > > + (notify_event == FS_MODIFY) ? > > + inode : NULL, 0); > > iput(p_inode); > > } > > > > kernfs_put(parent); > > } > > > > - if (!p_inode) > > - fsnotify_inode(inode, notify_event); > > + if (notify_event == FS_DELETE) > > + fsnotify_inoderemove(inode); > > + else if (!p_inode) > > + fsnotify_inode(inode, FS_MODIFY); > > Didn't you mean notify_event? Yes, that would be better. > Thanks, > Amir. Thanks for looking at my patches Amir, T.J.
