On Tue 28-06-22 15:29:08, Amir Goldstein wrote: > 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. Listing all groups and marks makes sense to me. Often enough I was extracting this information from a crashdump :). Dumping of events may be a bit more challenging (especially as we'd need to format the events which has some non-trivial implications) so I'm not 100% convinced about that. I agree it might be useful but I'd have to see the implementation... > 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). Yes, that was the original intent of FAN_CLASS_PRE_CONTENT AFAIK. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
