> On Nov 14, 2024, at 12:14 PM, Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Thu, Nov 14, 2024 at 12:44 AM Song Liu <song@xxxxxxxxxx> 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
