On Tue, Apr 21, 2026 at 3:50 PM Paul Moore <[email protected]> wrote: > > On Tue, Apr 21, 2026 at 6:15 PM Alexei Starovoitov > <[email protected]> wrote: > > On Tue, Apr 21, 2026 at 3:10 PM Paul Moore <[email protected]> wrote: > > > > > > > It's still Nack. > > > > > > Based solely on the diffstat and a quick look, this appears to be an > > > LSM patchset, not necessarily a BPF patchset; yes, there are kfuncs, > > > but they are LSM/audit kfuncs and not core BPF functionality. > > > Regardless, I want to see how the LSS presentation is received before > > > worrying about this too much, but your NACK has been noted. > > > > Paul, > > > > told you countless times LSM cannot touch BPF bits without > > explicit Ack. > > Based on a quick glance it doesn't appear that Fred's patches touch > BPF bits, they simply supply kfuncs for users to use in their BPF > programs. > > > So, no, you cannot add bpf kfuncs in random places in the kernel > > I see plenty of places outside of kernel/bpf that define kfuncs.
We discussed this already. All those places were explicitly acked by BPF maintainers. Every time somebody adds a kfunc it breaks safety, because people don't read or don't understand Documentation/bpf/kfuncs.rst. kfuncs are not export_symbol. Object ownership model needs to be thought through. Calling context needs to be analyzed and so on. Just because something "works for me" it doesn't mean that it's safe.
