Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes: > 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. Fine with me; I just assumed there was a good reason for the current behaviour :) Will do a v3 that just passes through the errors from the kernel. -Toke
