On Fri, Nov 08, 2019 at 02:50:43PM -0800, Andrii Nakryiko wrote: > On Fri, Nov 8, 2019 at 1:33 PM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > > > > From: Toke Høiland-Jørgensen <toke@xxxxxxxxxx> > > > > When loading an eBPF program, libbpf overrides the return code for EPERM > > errors instead of returning it to the caller. This makes it hard to figure > > out what went wrong on load. > > > > In particular, EPERM is returned when the system rlimit is too low to lock > > the memory required for the BPF program. Previously, this was somewhat > > obscured because the rlimit error would be hit on map creation (which does > > return it correctly). However, since maps can now be reused, object load > > can proceed all the way to loading programs without hitting the error; > > propagating it even in this case makes it possible for the caller to react > > appropriately (and, e.g., attempt to raise the rlimit before retrying). > > > > Acked-by: Song Liu <songliubraving@xxxxxx> > > Signed-off-by: Toke Høiland-Jørgensen <toke@xxxxxxxxxx> > > --- > > tools/lib/bpf/libbpf.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c > > index cea61b2ec9d3..582c0fd16697 100644 > > --- a/tools/lib/bpf/libbpf.c > > +++ b/tools/lib/bpf/libbpf.c > > @@ -3721,7 +3721,7 @@ load_program(struct bpf_program *prog, struct bpf_insn *insns, int insns_cnt, > > free(log_buf); > > goto retry_load; > > } > > - ret = -LIBBPF_ERRNO__LOAD; > > + ret = (errno == EPERM) ? -errno : -LIBBPF_ERRNO__LOAD; ouch. so libbpf was supressing all errnos for loading and that was a commit from 2015. No wonder it's hard to debug. I grepped every where I could and it doesn't look like anyone is using this code. There are other codes that can come from sys_bpf(prog_load). Not sure why such decision was made back then. I guess noone was really paying attention. I think we better propagate all codes. I don't see why EPERM should be special.
