Re: [PATCH v2 bpf-next 1/2] bpf: annotate file argument as __nullable in bpf_lsm_mmap_file

[Matt Bobrowski <mattbobrowski@google.com>]

On Wed, Dec 17, 2025 at 04:45:34AM +0900, Song Liu wrote:
> On Tue, Dec 16, 2025 at 5:30 AM Matt Bobrowski <mattbobrowski@google.com> wrote:
> [...]
> > diff --git a/kernel/bpf/Makefile b/kernel/bpf/Makefile
> > index 232cbc97434d..79cf22860a99 100644
> > --- a/kernel/bpf/Makefile
> > +++ b/kernel/bpf/Makefile
> > @@ -42,7 +42,17 @@ endif
> >  ifeq ($(CONFIG_BPF_JIT),y)
> >  obj-$(CONFIG_BPF_SYSCALL) += bpf_struct_ops.o
> >  obj-$(CONFIG_BPF_SYSCALL) += cpumask.o
> > -obj-${CONFIG_BPF_LSM} += bpf_lsm.o
> > +# bpf_lsm_proto.o must precede bpf_lsm.o. The current pahole logic
> > +# deduplicates function prototypes within
> > +# btf_encoder__add_saved_func() by keeping the first instance seen. We
> > +# need the function prototype(s) in bpf_lsm_proto.o to take precedence
> > +# over those within bpf_lsm.o. Having bpf_lsm_proto.o precede
> > +# bpf_lsm.o ensures its DWARF CU is processed early, forcing the
> > +# generated BTF to contain the overrides.
> > +#
> > +# Notably, this is a temporary workaround whilst the deduplication
> > +# semantics within pahole are revisited accordingly.
> 
> This is quite tricky, but I can confirm we need bpf_lsm_proto.o first.

Yes, agree, but it's an outright "hack" at this point. Note that I'm
also going to send a fix addressing a shortcoming within pahole, as
per this thread [0]. I'm just waiting to see what the BTF experts have
to say about it.

[0] https://lore.kernel.org/bpf/aTlFKI2IeHQ2-TSE@google.com/