Re: [PATCH v1 bpf] libbpf: use proper errno value in linker

[Anton Protopopov <a.s.protopopov@gmail.com>]

On 25/04/30 09:05AM, Andrii Nakryiko wrote:
> On Wed, Apr 30, 2025 at 5:03 AM Anton Protopopov
> <a.s.protopopov@gmail.com> wrote:
> >
> > Return values of the linker_append_sec_data() and the
> > linker_append_elf_relos() functions are propagated all the
> > way up to users of libbpf API. In some error cases these
> > functions return -1 which will be seen as -EPERM from user's
> > point of view. Instead, return a more reasonable -EINVAL.
> >
> > Fixes: faf6ed321cf6 ("libbpf: Add BPF static linker APIs")
> > Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com>
> > ---
> >  tools/lib/bpf/linker.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/lib/bpf/linker.c b/tools/lib/bpf/linker.c
> > index 56f5068e2eba..a469e5d4fee7 100644
> > --- a/tools/lib/bpf/linker.c
> > +++ b/tools/lib/bpf/linker.c
> > @@ -1376,7 +1376,7 @@ static int linker_append_sec_data(struct bpf_linker *linker, struct src_obj *obj
> >                 } else {
> >                         if (!secs_match(dst_sec, src_sec)) {
> >                                 pr_warn("ELF sections %s are incompatible\n", src_sec->sec_name);
> > -                               return -1;
> > +                               return -EINVAL;
> >                         }
> >
> >                         /* "license" and "version" sections are deduped */
> > @@ -2223,7 +2223,7 @@ static int linker_append_elf_relos(struct bpf_linker *linker, struct src_obj *ob
> >                         }
> >                 } else if (!secs_match(dst_sec, src_sec)) {
> >                         pr_warn("sections %s are not compatible\n", src_sec->sec_name);
> > -                       return -1;
> > +                       return -EINVAL;
> 
> doh, not sure how that slipped through, thanks for the fix! I applied
> it to bpf-next.

At least, not bool or so :) I've found it, because I was copy/pasting this
particular piece of code.

> BTW, if you would be so kind, I think we have a similar issue with
> validate_nla() in nlattr.c, where -1 can be eventually returned as
> user-visible error code, it would be nice to fix this up like you did
> with linker APIs, thanks!

Ok, sure, I will take a look.

> 
> >                 }
> >
> >                 /* shdr->sh_link points to SYMTAB */
> > --
> > 2.34.1
> >