Subject: Re: [PATCH bpf] samples/bpf: Set rlimit for memlock to infinity in all samples

From: Jesper Dangaard Brouer <[email-masked]>
Date: Tue, 27 Oct 2020 08:14:40 +0100

On Tue, 27 Oct 2020 00:36:23 +0100
Toke Høiland-Jørgensen <[email-masked]> wrote:

> The memlock rlimit is a notorious source of failure for BPF programs. Most
> of the samples just set it to infinity, but a few used a lower limit. The
> problem with unconditionally setting a lower limit is that this will also
> override the limit if the system-wide setting is *higher* than the limit
> being set, which can lead to failures on systems that lock a lot of memory,
> but set 'ulimit -l' to unlimited before running a sample.
> 
> One fix for this is to only conditionally set the limit if the current
> limit is lower, but it is simpler to just unify all the samples and have
> them all set the limit to infinity.
> 
> Signed-off-by: Toke Høiland-Jørgensen <[email-masked]>

This change basically disable the memlock rlimit system. And this
disable method is becoming standard in more and more BPF programs.
IMHO using the system-wide memlock rlimit doesn't make sense for BPF.

I'm still ACKing the patch, as this seems the only way forward, to
ignore and in-practice not use the memlock rlimit.

Acked-by: Jesper Dangaard Brouer <[email-masked]>

I saw some patches on the list (from Facebook) with a new system for
policy limiting memory usage per BPF program or was it mem-cgroup, but
I don't think that was ever merged... I would really like to see
something replace (and remove) this memlock rlimit dependency. Anyone
knows what happened to that effort?

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer