Re: [RFC] Volatile fanotify marks

[Matthew Bobrowski <repnop@google.com>]

On Mon, Feb 28, 2022 at 03:05:56PM +0100, Jan Kara wrote:
> Hi Amir!
> 
> On Wed 23-02-22 20:42:37, Amir Goldstein wrote:
> > I wanted to get your feedback on an idea I have been playing with.
> > It started as a poor man's alternative to the old subtree watch problem.
> > For my employer's use case, we are watching the entire filesystem using
> > a filesystem mark, but would like to exclude events on a subtree
> > (i.e. all files underneath .private/).
> > 
> > At the moment, those events are filtered in userspace.
> > I had considered adding directory marks with an ignored mask on every
> > event that is received for a directory path under .private/, but that has the
> > undesired side effect of pinning those directory inodes to cache.
> > 
> > I have this old fsnotify-volatile branch [1] that I am using for an overlayfs
> > kernel internal fsnotify backend. I wonder what are your thoughts on
> > exposing this functionally to fanotify UAPI (i.e. FAN_MARK_VOLATILE).
> 
> Interesting idea. I have some reservations wrt to the implementation (e.g.
> fsnotify_add_mark_list() convention of returning EEXIST when it updated
> mark's mask, or the fact that inode reclaim should now handle freeing of
> mark connector and attached marks - which may get interesting locking wise)
> but they are all fixable.
> 
> I'm wondering a bit whether this is really useful enough (and consequently
> whether we will not get another request to extend fanotify API in some
> other way to cater better to some other usecase related to subtree watches
> in the near future). I understand ignore marks are mainly a performance
> optimization and as such allowing inodes to be reclaimed (which means they
> are not used much and hence ignored mark is not very useful anyway) makes
> sense. Thinking about this more, I guess it is useful to improve efficiency
> when you want to implement any userspace event-filtering scheme.
> 
> The only remaining pending question I have is whether we should not go
> further and allow event filtering to happen using an eBPF program. That
> would be even more efficient (both in terms of memory and CPU). What do you
> think?

Wait. Did I just read that Jan is open to implementing in kernel event
filtering through eBPF? This feature is something that I'd definitely
be interested in and perhaps also open to running with doing the
design/implementation. One of the really obvious filtering semantics
that immediately comes to mind for me would be to filter on expected
processes/binary images touching an expected set of files. Currently,
this level of filtering has traditionally been done in userspace, but
if we could offload that it'd be nice...

/M