[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20191108.134307.2153170175114525963.davem@davemloft.net>
Date: Fri, 08 Nov 2019 13:43:07 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: toke@...hat.com
Cc: daniel@...earbox.net, ast@...nel.org, kafai@...com,
songliubraving@...com, yhs@...com, brouer@...hat.com,
andrii.nakryiko@...il.com, netdev@...r.kernel.org,
bpf@...r.kernel.org
Subject: Re: [PATCH bpf-next v2 3/6] libbpf: Propagate EPERM to caller on
program load
From: Toke Høiland-Jørgensen <toke@...hat.com>
Date: Fri, 08 Nov 2019 22:33:08 +0100
> 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, 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@...com>
> Signed-off-by: Toke Høiland-Jørgensen <toke@...hat.com>
Acked-by: David S. Miller <davem@...emloft.net>
Powered by blists - more mailing lists