> On Nov 15, 2024, at 1:05 PM, Song Liu <songliubraving@xxxxxxxx> wrote: [...] > >> >> fsnotify_open_perm->fsnotify->send_to_group->fanotify_handle_event. >> >> is a pretty long path to call bpf prog and >> preparing a giant 'struct fanotify_fastpath_event' >> is not going to fast either. >> >> If we want to accelerate that with bpf it needs to be done >> sooner with negligible overhead. > > Agreed. This is actually something I have been thinking > since the beginning of this work: Shall it be fanotify-bpf > or fsnotify-bpf. Given we have more materials, this is a > good time to have broader discussions on this. > > @all, please chime in whether we should redo this as > fsnotify-bpf. AFAICT: > > Pros of fanotify-bpf: > - There is existing user space that we can leverage/reuse. > > Pros of fsnotify-bpf: > - Faster fast path. > > Another major pros/cons did I miss? Adding more thoughts on this: I think it makes more sense to go with fanotify-bpf. This is because one of the benefits of fsnotify/fanotify over LSM solutions is the built-in event filtering of events. While this call chain is a bit long: fsnotify_open_perm->fsnotify->send_to_group->fanotify_handle_event. There are built-in filtering in fsnotify() and send_to_group(), so logics in the call chain are useful. struct fanotify_fastpath_event is indeed big. But I think we need to pass these information to the fastpath handler either way. Overall, I think current fastpath design makes sense, though there are things we need to fix (as Amir and Alexei pointed out). Please let me know comments and suggestions on this. Thanks, Song
