[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOQ4uxjbKgEoRM4DXBq0T3-jP96FCHjUY0PLsqVE0_s-hS3xLg@mail.gmail.com>
Date: Tue, 28 Jun 2022 16:55:25 +0300
From: Amir Goldstein <amir73il@...il.com>
To: Jan Kara <jack@...e.cz>
Cc: guowei du <duguoweisz@...il.com>,
Christian Brauner <brauner@...nel.org>,
Matthew Bobrowski <repnop@...gle.com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
duguowei <duguowei@...omi.com>
Subject: Re: [PATCH 6/6] fanotify: add current_user_instances node
On Tue, Jun 28, 2022 at 3:56 PM Jan Kara <jack@...e.cz> wrote:
>
> On Tue 28-06-22 15:29:08, Amir Goldstein wrote:
> > On Tue, Jun 28, 2022 at 2:50 PM guowei du <duguoweisz@...il.com> 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...
>
I don't really care about the events.
I would like to list the tasks that are blocked on permission events
and the fanotify reader process that blocks them, so that it could be killed.
Technically, it is enough to list the blocked task pids in fanotify_fdinfo().
But it is also low hanging to print the number of queued events
in fanotify_fdinfo() and inotify_fdinfo().
Thanks,
Amir.
Powered by blists - more mailing lists