Re: [RFC/PATCH v2 bpf-next fanotify 7/7] selftests/bpf: Add test for BPF based fanotify fastpath handler

[Song Liu <songliubraving@meta.com>]

> On Nov 14, 2024, at 12:14 PM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> 
> On Thu, Nov 14, 2024 at 12:44 AM Song Liu <song@kernel.org> wrote:
>> 
>> +
>> +       if (bpf_is_subdir(dentry, v->dentry))
>> +               ret = FAN_FP_RET_SEND_TO_USERSPACE;
>> +       else
>> +               ret = FAN_FP_RET_SKIP_EVENT;
> 
> It seems to me that all these patches and feature additions
> to fanotify, new kfuncs, etc are done just to do the above
> filtering by subdir ?
> 
> If so, just hard code this logic as an extra flag to fanotify ?
> So it can filter all events by subdir.
> bpf programmability makes sense when it needs to express
> user space policy. Here it's just a filter by subdir.
> bpf hammer doesn't look like the right tool for this use case.

Current version is indeed tailored towards the subtree 
monitoring use case. This is mostly because feedback on v1 
mostly focused on this use case. V1 itself actually had some
other use cases. 

In practice, fanotify fastpath can benefit from bpf 
programmability. For example, with bpf programmability, we 
can combine fanotify and BPF LSM in some security use cases. 
If some security rules only applies to a few files, a 
directory, or a subtree, we can use fanotify to only monitor 
these files. LSM hooks, such as security_file_open(), are
always global. The overhead is higher if we are only 
interested in a few files. 

Does this make sense?

Thanks,
Song