Hi folks, At LSF/MM/BPF 2025, I would like to continue the discussion on enabling in-kernel fanotify filter, with kernel modules or BPF programs.There are a few rounds of RFC/PATCH for this work:[1][2][3]. =============== Motivation ================= Currently, fanotify sends all events to user space, which is expensive. If the in-kernel filter can handle some events, it will be a clear win. Tracing and LSM BPF programs are always global. For systems that use different rules on different files/directories, the complexity and overhead of these tracing/LSM programs may grow linearly with the number of rules. fanotify, on the other hand, only enters the actual handlers for matching fanotify marks. Therefore, fanotify-bpf has the potential to be a more scalable alternative to tracing/LSM BPF programs. Monitoring of a sub-tree in the VFS has been a challenge for both fanotify [4] and BPF LSM [5]. One of the key motivations of this work is to provide a more efficient solution for sub-tree monitoring. =============== Challenge ================= The latest proposal for sub-tree monitoring is to have a per filesystem fanotify mark and use the filter function (in a kernel module or a BPF program) to filter events for the target sub-tree. This approach is not scalable for multiple rules within the same file system, and thus has little benefit over existing tracing/LSM BPF programs. A better approach would be use per directory fanotify marks. However, it is not yet clear how to manage these marks. A naive approach for this is to employ some directory walking mechanism to populate the marks to all sub directories in the sub-tree at the beginning; and then on mkdir, the child directory needs to inherit marks from the parent directory. I hope we can discuss the best solution for this in LSF/MM/BPF. Thanks, Song [1] v3: https://lore.kernel.org/bpf/20241122225958.1775625-1-song@xxxxxxxxxx/ [2] v2: https://lore.kernel.org/bpf/20241114084345.1564165-1-song@xxxxxxxxxx/ [3] v1: https://lore.kernel.org/bpf/20241029231244.2834368-1-song@xxxxxxxxxx/ [4] https://lpc.events/event/18/contributions/1717/ [5] https://lpc.events/event/18/contributions/1940/
