[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220120041025.uhg2mgpgl32mnjtq@ast-mbp.dhcp.thefacebook.com>
Date: Wed, 19 Jan 2022 20:10:25 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Song Liu <song@...nel.org>
Cc: bpf@...r.kernel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, ast@...nel.org, daniel@...earbox.net,
andrii@...nel.org, kernel-team@...com, peterz@...radead.org,
x86@...nel.org, Song Liu <songliubraving@...com>
Subject: Re: [PATCH v4 bpf-next 2/7] bpf: use bytes instead of pages for
bpf_jit_[charge|uncharge]_modmem
On Wed, Jan 19, 2022 at 03:06:15PM -0800, Song Liu wrote:
> From: Song Liu <songliubraving@...com>
>
> This enables sub-page memory charge and allocation.
>
> Signed-off-by: Song Liu <songliubraving@...com>
> ---
> include/linux/bpf.h | 4 ++--
> kernel/bpf/core.c | 19 +++++++++----------
> kernel/bpf/trampoline.c | 6 +++---
> 3 files changed, 14 insertions(+), 15 deletions(-)
>
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 6d7346c54d83..920940f7be22 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -827,8 +827,8 @@ void bpf_image_ksym_add(void *data, struct bpf_ksym *ksym);
> void bpf_image_ksym_del(struct bpf_ksym *ksym);
> void bpf_ksym_add(struct bpf_ksym *ksym);
> void bpf_ksym_del(struct bpf_ksym *ksym);
> -int bpf_jit_charge_modmem(u32 pages);
> -void bpf_jit_uncharge_modmem(u32 pages);
> +int bpf_jit_charge_modmem(u32 size);
> +void bpf_jit_uncharge_modmem(u32 size);
> bool bpf_prog_has_trampoline(const struct bpf_prog *prog);
> #else
> static inline int bpf_trampoline_link_prog(struct bpf_prog *prog,
> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index de3e5bc6781f..495e3b2c36ff 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -808,7 +808,7 @@ int bpf_jit_add_poke_descriptor(struct bpf_prog *prog,
> return slot;
> }
>
> -static atomic_long_t bpf_jit_current;
> +static atomic64_t bpf_jit_current;
I don't understand the motivation for this change.
bpf_jit_limit is type "long" and it's counting in bytes.
So why change jit_current to atomic64?
atomic_long will be fine even on 32-bit arch.
What did I miss?
Powered by blists - more mailing lists