[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <68FB5A08-C8DA-4D64-949C-C725483A9999@fb.com>
Date: Fri, 8 Nov 2019 19:36:05 +0000
From: Song Liu <songliubraving@...com>
To: Toke Høiland-Jørgensen <toke@...hat.com>
CC: Daniel Borkmann <daniel@...earbox.net>,
Alexei Starovoitov <ast@...nel.org>, Martin Lau <kafai@...com>,
Yonghong Song <yhs@...com>,
Jesper Dangaard Brouer <brouer@...hat.com>,
Andrii Nakryiko <andrii.nakryiko@...il.com>,
David Miller <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"bpf@...r.kernel.org" <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next 3/6] libbpf: Propagate EPERM to caller on program
load
> On Nov 7, 2019, at 8:52 AM, Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>
> From: Toke Høiland-Jørgensen <toke@...hat.com>
>
> 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, sine maps can now be reused, object load can
^^ since
> 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@...hat.com>
Acked-by: Song Liu <songliubraving@...com>
Powered by blists - more mailing lists