Re: [PATCH RFC bpf-next 0/4] audit: Expose audit subsystem to BPF LSM programs via BPF kfuncs

Hi Alexei & Paul,

Thanks for the comments. I did not mean for the talk announcement to
end in this state.

I understood the RFC was NACK'd, but I thought having a talk at LSS
could open up for some additional discussion around what can be done
with audit to make it more BPF friendly. I apologize.

My assumption is that the committee would've denied the talk if there
wasn't _some_ interest here. And still intend to give it unless
committee decides to revoke it, because there is always opportunity
to improve subsystems.

On Wed, Apr 22, 2026 at 10:33:27AM -0400, Paul Moore wrote:
> On Tue, Apr 21, 2026 at 7:08 PM Alexei Starovoitov
> > 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.

I interpreted this comment as more broadly applied to patch
submissions in general, and not this patch series itself (necessarily).

I do think that "... it breaks saftey ... kfuncs are not export_symbol"
is what the crux here is. I argue that that Documentation/bpf/kfuncs.rst
should be improved if this is a common trap that I and others fall in.

As I understood kfuncs, the point is to move away from BPF helpers so
that subsystems can have a export_symbol of sorts.

To quote:

	BPF Kernel Functions or more commonly known as kfuncs are functions
	in the Linux kernel which are exposed for use by BPF programs
	Unlike normal BPF helpers, kfuncs do not have a stable interface
	and can change from one kernel release to another.
	...

As Paul mentioned, there are examples of the export_symbols use case, and
even one whose sole purpose is to crash the kernel: crash_kexec()[1]
And to be clear, I don't think that is a bad or uneeded patch. I just find it
interesting and unexpected that it was applied.

Maybe this series is the straw that breaks the camel's back?

> 
> 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.
> 

Agreed. I can work with addressing calling context and object ownership
concerns. I thought I addressed these, but I'd like to know if there's
something I didn't consider.

Best,
Fred

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=133790596406ce2658f0864eb7eac64987c2b12f