Re: [PATCH bpf-next v2 1/2] selftests/bpf: Annotate bpf_obj_new_impl() with __must_check

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Aug 27, 2025 at 11:34 AM Ilya Leoshkevich <iii@xxxxxxxxxxxxx> wrote:
>
> On Wed, 2025-08-27 at 10:32 -0700, Andrii Nakryiko wrote:
> > On Wed, Aug 27, 2025 at 6:05 AM Ilya Leoshkevich <iii@xxxxxxxxxxxxx>
> > wrote:
> > >
> > > The verifier requires that pointers returned by bpf_obj_new_impl()
> > > are
> > > either dropped or stored in a map. Therefore programs that do not
> > > use
> > > its return values will fail to load. Make the compiler point out
> > > these
> > > issues. Adjust selftests that check that the verifier does indeed
> > > spot
> > > these bugs.
> > >
> > > Link:
> > > https://lore.kernel.org/bpf/CAADnVQL6Q+QRv3_JwEd26biwGpFYcwD_=BjBJWLAtpgOP9CKRw@xxxxxxxxxxxxxx/
> > > Suggested-by: Alexei Starovoitov <ast@xxxxxxxxxx>
> > > Signed-off-by: Ilya Leoshkevich <iii@xxxxxxxxxxxxx>
> > > ---
> > >  tools/lib/bpf/bpf_helpers.h                          | 4 ++++
> > >  tools/testing/selftests/bpf/bpf_experimental.h       | 2 +-
> > >  tools/testing/selftests/bpf/progs/linked_list_fail.c | 8 ++++----
> > >  3 files changed, 9 insertions(+), 5 deletions(-)
>
> The CI found an issue with bpf-gcc in the meantime, I will fix this in
> v3.
>
> > > diff --git a/tools/lib/bpf/bpf_helpers.h
> > > b/tools/lib/bpf/bpf_helpers.h
> > > index 80c028540656..e1496a328e3f 100644
> > > --- a/tools/lib/bpf/bpf_helpers.h
> > > +++ b/tools/lib/bpf/bpf_helpers.h
> > > @@ -69,6 +69,10 @@
> > >   */
> > >  #define __hidden __attribute__((visibility("hidden")))
> > >
> > > +#ifndef __must_check
> > > +#define __must_check __attribute__((__warn_unused_result__))
> > > +#endif
> > > +
> >
> > do we need to add this to libbpf UAPI? let's put it in selftests
> > header somewhere instead?
>
> Will do.
>
> >
> > >  /* When utilizing vmlinux.h with BPF CO-RE, user BPF programs
> > > can't include
> > >   * any system-level headers (such as stddef.h, linux/version.h,
> > > etc), and
> > >   * commonly-used macros like NULL and KERNEL_VERSION aren't
> > > available through
> > > diff --git a/tools/testing/selftests/bpf/bpf_experimental.h
> > > b/tools/testing/selftests/bpf/bpf_experimental.h
> > > index da7e230f2781..e5ef4792da42 100644
> > > --- a/tools/testing/selftests/bpf/bpf_experimental.h
> > > +++ b/tools/testing/selftests/bpf/bpf_experimental.h
> > > @@ -20,7 +20,7 @@
> > >   *     A pointer to an object of the type corresponding to the
> > > passed in
> > >   *     'local_type_id', or NULL on failure.
> > >   */
> > > -extern void *bpf_obj_new_impl(__u64 local_type_id, void *meta)
> > > __ksym;
> > > +extern __must_check void *bpf_obj_new_impl(__u64 local_type_id,
> > > void *meta) __ksym;
> >
> > bpf_obj_new_impl will generally come from vmlinux.h nowadays, and
> > that
> > one won't have __must_check annotation, is that a problem?
>
> It should be fine according to [1]:
>
> Compatible attribute specifications on distinct declarations of the
> same function are merged.
>
> I will add this to the commit message in v3.

Sure, for BPF selftests it will work. My question was broader, for
anyone using bpf_obj_new in the wild, they won't have __must_check
annotation from vmlinux.h (and I doubt they will manually add it like
we do here for BPF selftests), so if that's important, I guess we need
to think how to wire that up so that it happens automatically through
vmlinux.h.

"It's not that important to bother" is a fine answer as well :)

>
> [1]
> https://gcc.gnu.org/onlinedocs/gcc-12.4.0/gcc/Function-Attributes.html
>
> [...]





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux