On Tue, Apr 21, 2026 at 7:08 PM Alexei Starovoitov <[email protected]> wrote: > 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.
Perhaps. However, we don't have to look further than your first response in this thread to notice a prejudice against existing in-kernel security/auditing mechanisms that large numbers of users rely on every day. While I'll continue to try working with you, and encourage others to do the same, you've forced me into a position where I need to consider sending patches to Linus that you've NACK'd. I don't like it, it indicates a cultural breakdown and the formation of rigid silos/fiefdoms within the kernel community, but I have a responsibility to the other developers and users to represent and advocate for their security needs. > 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. Unfortunately that isn't the review you provided Fred in this thread. There were no comments about object ownership, calling context, safety, etc., only a dismissive comment telling Fred to use something else for logging. If you want to provide proper feedback, something along the lines of Kumar's constructive review, I think Fred would welcome that. -- paul-moore.com
