Re: [PATCH 6/6] fanotify: add current_user_instances node

From: Christian Brauner <brauner@kernel.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>, guowei du <duguoweisz@gmail.com>,
	Matthew Bobrowski <repnop@google.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	duguowei <duguowei@xiaomi.com>
Subject: Re: [PATCH 6/6] fanotify: add current_user_instances node
Date: Tue, 28 Jun 2022 16:25:32 +0200	[thread overview]
Message-ID: <20220628142532.rinam6psfflxkimv@wittgenstein> (raw)
In-Reply-To: <CAOQ4uxjbKgEoRM4DXBq0T3-jP96FCHjUY0PLsqVE0_s-hS3xLg@mail.gmail.com>

On Tue, Jun 28, 2022 at 04:55:25PM +0300, Amir Goldstein wrote:
> On Tue, Jun 28, 2022 at 3:56 PM Jan Kara <jack@suse.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@gmail.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().

That's always going to be racy, right? You might list the blocked tasks
but it's impossible for userspace to ensure that the pids it parses
still refer to the same processes by the time it tries to kill them.

You would need an interface that allows you to kill specific blocked
tasks or at least all blocked tasks. You could just make this an - ahem
- ioctl on a suitable fanotify fd and somehow ensure that the task is
actually the one you want to kill?

If you can avoid adding a whole new /sys/kernel/fanotify/ interface
that'd be quite nice for userspace, I think.