[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20210924095542.33697-1-lmb@cloudflare.com>
Date: Fri, 24 Sep 2021 10:55:38 +0100
From: Lorenz Bauer <lmb@...udflare.com>
To: Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>
Cc: kernel-team@...udflare.com, Lorenz Bauer <lmb@...udflare.com>,
linux-riscv@...ts.infradead.org, netdev@...r.kernel.org,
bpf@...r.kernel.org
Subject: [PATCH bpf-next 0/4] Fix up bpf_jit_limit some more
Some more cleanups around bpf_jit_limit to make it readable via sysctl.
Things I'm not sure about:
* Is it OK to expose atomic_long_t bpf_jit_limit like this? The sysctl code
isn't atomic, but maybe it's fine because it's read only.
* All of the JIT related sysctls are quite restrictive, you have to have
CAP_SYS_ADMIN / CAP_BPF _and_ be root as well. This makes it problematic
to scrape these to expose them as metrics. Can we relax this somewhat?
Lorenz
Lorenz Bauer (4):
bpf: define bpf_jit_alloc_exec_limit for riscv JIT
bpf: define bpf_jit_alloc_exec_limit for arm64 JIT
bpf: prevent increasing bpf_jit_limit above max
bpf: export bpf_jit_current
arch/arm64/net/bpf_jit_comp.c | 5 +++++
arch/riscv/net/bpf_jit_core.c | 5 +++++
include/linux/filter.h | 2 ++
kernel/bpf/core.c | 7 ++++---
net/core/sysctl_net_core.c | 9 ++++++++-
5 files changed, 24 insertions(+), 4 deletions(-)
--
2.30.2
Powered by blists - more mailing lists