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
Expose the maximum amount of useable memory from the sparcv JIT.
Signed-off-by: Lorenz Bauer <redacted>
---
arch/riscv/net/bpf_jit_core.c | 5 +++++
1 file changed, 5 insertions(+)
@@ -524,6 +524,7 @@ int bpf_jit_enable __read_mostly = IS_BUILTIN(CONFIG_BPF_JIT_DEFAULT_ON);intbpf_jit_kallsyms__read_mostly=IS_BUILTIN(CONFIG_BPF_JIT_DEFAULT_ON);intbpf_jit_harden__read_mostly;longbpf_jit_limit__read_mostly;+longbpf_jit_limit_max__read_mostly;staticvoidbpf_prog_ksym_set_addr(structbpf_prog*prog)
@@ -817,7 +818,8 @@ u64 __weak bpf_jit_alloc_exec_limit(void)staticint__initbpf_jit_charge_init(void){/* Only used as heuristic here to derive limit. */-bpf_jit_limit=min_t(u64,round_up(bpf_jit_alloc_exec_limit()>>2,+bpf_jit_limit_max=bpf_jit_alloc_exec_limit();+bpf_jit_limit=min_t(u64,round_up(bpf_jit_limit_max>>2,PAGE_SIZE),LONG_MAX);return0;}
Expose the maximum amount of useable memory from the arm64 JIT.
Signed-off-by: Lorenz Bauer <redacted>
---
arch/arm64/net/bpf_jit_comp.c | 5 +++++
1 file changed, 5 insertions(+)
@@ -525,6 +525,7 @@ int bpf_jit_kallsyms __read_mostly = IS_BUILTIN(CONFIG_BPF_JIT_DEFAULT_ON);intbpf_jit_harden__read_mostly;longbpf_jit_limit__read_mostly;longbpf_jit_limit_max__read_mostly;+atomic_long_tbpf_jit_current__read_mostly;staticvoidbpf_prog_ksym_set_addr(structbpf_prog*prog)
@@ -800,8 +801,6 @@ int bpf_jit_add_poke_descriptor(struct bpf_prog *prog,returnslot;}-staticatomic_long_tbpf_jit_current;-/* Can be overridden by an arch's JIT compiler if it has a custom,*dedicatedBPFbackendmemoryarea,orifneitherofthetwo*belowapply.
@@ -525,6 +525,7 @@ int bpf_jit_kallsyms __read_mostly = IS_BUILTIN(CONFIG_BPF_JIT_DEFAULT_ON);intbpf_jit_harden__read_mostly;longbpf_jit_limit__read_mostly;longbpf_jit_limit_max__read_mostly;+atomic_long_tbpf_jit_current__read_mostly;staticvoidbpf_prog_ksym_set_addr(structbpf_prog*prog)
@@ -800,8 +801,6 @@ int bpf_jit_add_poke_descriptor(struct bpf_prog *prog,returnslot;}-staticatomic_long_tbpf_jit_current;-/* Can be overridden by an arch's JIT compiler if it has a custom,*dedicatedBPFbackendmemoryarea,orifneitherofthetwo*belowapply.
Overall series looks good to me. The only nit I would have is that the above could (in theory)
be subject to atomic_long_t vs long type confusion. I would rather prefer to have a small handler
which properly reads out the atomic_long_t and then passes it onwards as a temporary/plain long
to user space.
Thanks,
Daniel
From: Jakub Sitnicki <jakub@cloudflare.com> Date: 2021-09-27 14:02:06
On Mon, Sep 27, 2021 at 03:34 PM CEST, Daniel Borkmann wrote:
On 9/24/21 11:55 AM, Lorenz Bauer wrote:
quoted
Expose bpf_jit_current as a read only value via sysctl.
Signed-off-by: Lorenz Bauer <redacted>
---
I find exposing stats via system configuration variables a bit
unexpected. Not sure if there is any example today that we're following.
Maybe an entry under /sys/kernel/debug would be a better fit?
That way we don't have to commit to a sysctl that might go away if we
start charging JIT allocs against memory cgroup quota.
Although that brings up question against which cgroup iptables xt_bpf
allocations should be charged? Root cgroup?
On Mon, 27 Sept 2021 at 15:01, Jakub Sitnicki [off-list ref] wrote:
I find exposing stats via system configuration variables a bit
unexpected. Not sure if there is any example today that we're following.
Maybe an entry under /sys/kernel/debug would be a better fit?
That way we don't have to commit to a sysctl that might go away if we
start charging JIT allocs against memory cgroup quota.
I had a look around, there are no other obvious places in debugfs or
proc where we already have bpf info exposed. It currently all goes via
sysctl.
There are examples of readonly sysctls:
$ sudo find /proc/sys -perm 0444 | wc -l
90
There are no examples of sysctls with mode 0400 however:
$ sudo find /proc/sys -perm 0400 | wc -l
0
I find it kind of weird that the bpf sysctls are so tightly locked
down (CAP_SYS_ADMIN && root) even for reading. Maybe something I can
change?
--
Lorenz Bauer | Systems Engineer
6th Floor, County Hall/The Riverside Building, SE1 7PB, UK
www.cloudflare.com
From: Will Deacon <will@kernel.org> Date: 2021-09-29 16:18:17
On Fri, Sep 24, 2021 at 10:55:40AM +0100, Lorenz Bauer wrote:
quoted hunk
Expose the maximum amount of useable memory from the arm64 JIT.
Signed-off-by: Lorenz Bauer <redacted>
---
arch/arm64/net/bpf_jit_comp.c | 5 +++++
1 file changed, 5 insertions(+)
Looks like this won't result in a functional change, as we happen to return
SZ_128M anyway thanks to the way in which the modules area is constructed.
But making this explicit is definitely better, so:
Acked-by: Will Deacon <will@kernel.org>
(I'm assuming this will go via the bpf tree, but please shout if I should
take it via arm64 instead)
Will