On Wed, Feb 18, 2026 at 10:37 AM Jan Kara <[email protected]> wrote: > > On Wed 18-02-26 10:06:35, T.J. Mercier wrote: > > On Wed, Feb 18, 2026 at 10:01 AM Jan Kara <[email protected]> wrote: > > > > > > On Tue 17-02-26 19:22:31, 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. > > > > > > Please see my email: > > > https://lore.kernel.org/all/lc2jgt3yrvuvtdj2kk7q3rloie2c5mzyhfdy4zvxylx732voet@ol3kl4ackrpb > > > > > > I think this is actually a bug in kernfs... > > > > > > Honza > > > > Thanks, I'm looking at this now. I've tried calling clear_nlink in > > kernfs_iop_rmdir, but I've found that when we get back to vfs_rmdir > > and shrink_dcache_parent is called, d_walk doesn't find any entries, > > so shrink_kill->__dentry_kill is not called. I'm investigating why > > that is... > > Strange because when I was experimenting with this in my VM I have seen > __dentry_kill being called (if the dentries were created by someone looking > up the names).
Ahh yes, that's the difference. I was just doing mkdir /sys/fs/cgroup/foo immediately followed by rmdir /sys/fs/cgroup/foo. kernfs creates the dentries in kernfs_iop_lookup, so there were none when I did the rmdir because I didn't cause any lookups. If I actually have a program watching /sys/fs/cgroup/foo/memory.events, then I do see the __dentry_kill kill calls, but despite the prior clear_nlink call i_nlink is 1 so fsnotify_inoderemove is skipped. Something must be incrementing it.
