On Thu, Nov 14, 2024 at 9: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. Good question. Speaking as someone who has made several attempts to design efficient subtree filtering in fanotify, it is not as easy as it sounds. I recently implemented a method that could be used for "practical" subdir filtering in userspace, not before Jan has questioned if we should go directly to subtree filtering with bpf [1]. This is not the only filter that was proposed for fanotify, where bpf filter came as an alternative proposal [2], but subtree filtering is by far the most wanted filter. The problem with implementing a naive is_subtree() filter in fanotify is the unbounded cost to be paid by every user for every fs access when M such filters are installed deep in the fs tree. Making this more efficient then becomes a matter of trading of memory (inode/path cache size) and performance and depends on the size and depth of the watched filesystem. This engineering decision *is* the userspace policy that can be expressed by a bpf program. As you may know, Linux is lagging behind Win and MacOS w.r.t subtree filtering for fs events. MacOS/FreeBSD took the userspace approach with fseventsd [3]. If you Google "fseventsd", you will get results with "High CPU and Memory Usage" for as far as the browser can scroll. I hope the bpf-aided early subtree filtering technology would be able to reduce some of this overhead to facilitate a better engineering solution, but that remains to be proven... Thanks, Amir. [1] https://lore.kernel.org/linux-fsdevel/20220228140556.ae5rhgqsyzm5djbp@xxxxxxxxxx/ [2] https://lore.kernel.org/linux-fsdevel/20200828084603.GA7072@xxxxxxxxxxxxxx/ [3] https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/FSEvents_ProgGuide/TechnologyOverview/TechnologyOverview.html#//apple_ref/doc/uid/TP40005289-CH3-SW1
