On Tue, Jun 28, 2022 at 2:50 PM guowei du <duguoweisz@xxxxxxxxx> wrote: > > hi, Mr Kara, Mr Brauner, > > I want to know how many fanotify readers are monitoring the fs event. > If userspace daemons monitoring all file system events are too many, maybe there will be an impact on performance. > I want something else which is more than just the number of groups. I want to provide the admin the option to enumerate over all groups and list their marks and blocked events. This would be similar to listing all the fdinfo of anon_inode:[fanotify] fds of processes that initialised fanotify groups. This enumeration could be done for example in /sys/fs/fanotify/groups/ My main incentive is not only the enumeration. My main incentive is to provide an administrative interface to check for any fs operations that are currently blocked by a rogue fanotify permission events reader and an easy way for administrators to kill those rogue processes (i.e. buggy anti-malware). This interface is inspired by the ability to enumerate and abort fuse connections for rogue fuse servers. I want to do that for the existing permission events as a prerequisite to adding new blocking events to be used for implementation of hierarchical storage managers, similar the Windows ProjFs [1]. This was allegedly the intended use case for group class FAN_CLASS_PRE_CONTENT (see man page). Do you want to implement the first step of enumerating fdinfo of all groups via /sys/fs/fanotify/groups/? Jan, If you have objections to any of the ideas above please shout. I was going to prepare a roadmap for blocking events and post it for comments, but this patch triggered a heads up. Thanks, Amir. [1] https://docs.microsoft.com/en-us/windows/win32/projfs/projected-file-system
