Commit 4f33ddb4 authored Nov 09, 2019 by Toke Høiland-Jørgensen Committed by Alexei Starovoitov Nov 10, 2019

libbpf: Propagate EPERM to caller on program load

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).

Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: Song Liu <songliubraving@fb.com>
Link: https://lore.kernel.org/bpf/157333184946.88376.11768171652794234561.stgit@toke.dk

parent 9c4e395a

tools/lib/bpf/libbpf.c

+11 −16

Original line number	Diff line number	Diff line
		@@ -3721,7 +3721,7 @@ retry_load:
		free(log_buf);
		goto retry_load;
		}
		ret = -LIBBPF_ERRNO__LOAD;
		ret = -errno;
		cp = libbpf_strerror_r(errno, errmsg, sizeof(errmsg));
		pr_warn("load bpf program failed: %s\n", cp);

		@@ -3734,9 +3734,8 @@ retry_load:
		pr_warn("Program too large (%zu insns), at most %d insns\n",
		load_attr.insns_cnt, BPF_MAXINSNS);
		ret = -LIBBPF_ERRNO__PROG2BIG;
		} else {
		} else if (load_attr.prog_type != BPF_PROG_TYPE_KPROBE) {
		/* Wrong program type? */
		if (load_attr.prog_type != BPF_PROG_TYPE_KPROBE) {
		int fd;

		load_attr.prog_type = BPF_PROG_TYPE_KPROBE;
		@@ -3749,10 +3748,6 @@ retry_load:
		}
		}

		if (log_buf)
		ret = -LIBBPF_ERRNO__KVER;
		}

		out:
		free(log_buf);
		return ret;

Admin message