From: Daniel Borkmann <daniel@iogearbox.net>
To: Lorenz Bauer <lmb@cloudflare.com>,
Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>
Cc: kernel-team@cloudflare.com, netdev@vger.kernel.org,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next 4/4] bpf: export bpf_jit_current
Date: Mon, 27 Sep 2021 15:34:40 +0200 [thread overview]
Message-ID: <a076398b-f1da-c939-3c71-ac157ad96939@iogearbox.net> (raw)
In-Reply-To: <20210924095542.33697-5-lmb@cloudflare.com>
On 9/24/21 11:55 AM, Lorenz Bauer wrote:
> Expose bpf_jit_current as a read only value via sysctl.
>
> Signed-off-by: Lorenz Bauer <lmb@cloudflare.com>
> ---
> include/linux/filter.h | 1 +
> kernel/bpf/core.c | 3 +--
> net/core/sysctl_net_core.c | 7 +++++++
> 3 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/filter.h b/include/linux/filter.h
> index ef03ff34234d..b2143ad5ce00 100644
> --- a/include/linux/filter.h
> +++ b/include/linux/filter.h
> @@ -1052,6 +1052,7 @@ extern int bpf_jit_harden;
> extern int bpf_jit_kallsyms;
> extern long bpf_jit_limit;
> extern long bpf_jit_limit_max;
> +extern atomic_long_t bpf_jit_current;
>
> typedef void (*bpf_jit_fill_hole_t)(void *area, unsigned int size);
>
> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index e844a2a4c99a..93f95e9ee8be 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -525,6 +525,7 @@ int bpf_jit_kallsyms __read_mostly = IS_BUILTIN(CONFIG_BPF_JIT_DEFAULT_ON);
> int bpf_jit_harden __read_mostly;
> long bpf_jit_limit __read_mostly;
> long bpf_jit_limit_max __read_mostly;
> +atomic_long_t bpf_jit_current __read_mostly;
>
> static void
> bpf_prog_ksym_set_addr(struct bpf_prog *prog)
> @@ -800,8 +801,6 @@ int bpf_jit_add_poke_descriptor(struct bpf_prog *prog,
> return slot;
> }
>
> -static atomic_long_t bpf_jit_current;
> -
> /* Can be overridden by an arch's JIT compiler if it has a custom,
> * dedicated BPF backend memory area, or if neither of the two
> * below apply.
> diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
> index 5f88526ad61c..674aac163b84 100644
> --- a/net/core/sysctl_net_core.c
> +++ b/net/core/sysctl_net_core.c
> @@ -421,6 +421,13 @@ static struct ctl_table net_core_table[] = {
> .extra1 = &long_one,
> .extra2 = &bpf_jit_limit_max,
> },
> + {
> + .procname = "bpf_jit_current",
> + .data = &bpf_jit_current,
> + .maxlen = sizeof(long),
> + .mode = 0400,
> + .proc_handler = proc_dolongvec_minmax_bpf_restricted,
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
> + },
> #endif
> {
> .procname = "netdev_tstamp_prequeue",
>
next prev parent reply other threads:[~2021-09-27 13:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-24 9:55 [PATCH bpf-next 0/4] Fix up bpf_jit_limit some more Lorenz Bauer
2021-09-24 9:55 ` Lorenz Bauer
2021-09-24 9:55 ` [PATCH bpf-next 1/4] bpf: define bpf_jit_alloc_exec_limit for riscv JIT Lorenz Bauer
2021-09-24 9:55 ` Lorenz Bauer
2021-09-24 15:28 ` Luke Nelson
2021-09-24 15:28 ` Luke Nelson
2021-09-24 9:55 ` [PATCH bpf-next 2/4] bpf: define bpf_jit_alloc_exec_limit for arm64 JIT Lorenz Bauer
2021-09-24 9:55 ` Lorenz Bauer
2021-09-29 16:18 ` Will Deacon
2021-09-29 16:18 ` Will Deacon
2021-09-24 9:55 ` [PATCH bpf-next 3/4] bpf: prevent increasing bpf_jit_limit above max Lorenz Bauer
2021-09-24 9:55 ` [PATCH bpf-next 4/4] bpf: export bpf_jit_current Lorenz Bauer
2021-09-27 13:34 ` Daniel Borkmann [this message]
2021-09-27 14:01 ` Jakub Sitnicki
2021-09-28 9:02 ` Lorenz Bauer
2021-09-29 14:56 ` Nicolas Dichtel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a076398b-f1da-c939-3c71-ac157ad96939@iogearbox.net \
--to=daniel@iogearbox.net \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=kernel-team@cloudflare.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lmb@cloudflare.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.