On 25/04/30 09:05AM, Andrii Nakryiko wrote:
> On Wed, Apr 30, 2025 at 5:03 AM Anton Protopopov
> <a.s.protopopov@xxxxxxxxx> 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@xxxxxxxxx>
> > ---
> > 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
> >
