From: Dennis Zhou <dennis@kernel.org>
To: Hou Tao <houtao@huaweicloud.com>
Cc: bpf@vger.kernel.org, linux-mm@kvack.org,
Martin KaFai Lau <martin.lau@linux.dev>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Andrii Nakryiko <andrii@kernel.org>, Song Liu <song@kernel.org>,
Hao Luo <haoluo@google.com>,
Yonghong Song <yonghong.song@linux.dev>,
Daniel Borkmann <daniel@iogearbox.net>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Jiri Olsa <jolsa@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
houtao1@huawei.com, Tejun Heo <tj@kernel.org>,
Christoph Lameter <cl@linux.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH bpf-next 1/6] mm/percpu.c: introduce alloc_size_percpu()
Date: Sun, 8 Oct 2023 15:32:15 -0700 [thread overview]
Message-ID: <ZSMt70tuBrHlI0Xa@snowbird> (raw)
In-Reply-To: <20231007135106.3031284-2-houtao@huaweicloud.com>
Hello,
On Sat, Oct 07, 2023 at 09:51:01PM +0800, Hou Tao wrote:
> From: Hou Tao <houtao1@huawei.com>
>
> Introduce alloc_size_percpu() to get the size of the dynamic per-cpu
> area. It will be used by bpf memory allocator in the following patches.
> BPF memory allocator maintains multiple per-cpu area caches for multiple
> area sizes and it needs the size of dynamic per-cpu area to select the
> corresponding cache when bpf program frees the dynamic per-cpu area.
>
> Signed-off-by: Hou Tao <houtao1@huawei.com>
> ---
> include/linux/percpu.h | 1 +
> mm/percpu.c | 29 +++++++++++++++++++++++++++++
> 2 files changed, 30 insertions(+)
>
> diff --git a/include/linux/percpu.h b/include/linux/percpu.h
> index 68fac2e7cbe6..d140d9d79567 100644
> --- a/include/linux/percpu.h
> +++ b/include/linux/percpu.h
> @@ -132,6 +132,7 @@ extern void __init setup_per_cpu_areas(void);
> extern void __percpu *__alloc_percpu_gfp(size_t size, size_t align, gfp_t gfp) __alloc_size(1);
> extern void __percpu *__alloc_percpu(size_t size, size_t align) __alloc_size(1);
> extern void free_percpu(void __percpu *__pdata);
> +extern size_t alloc_size_percpu(void __percpu *__pdata);
>
> DEFINE_FREE(free_percpu, void __percpu *, free_percpu(_T))
>
> diff --git a/mm/percpu.c b/mm/percpu.c
> index 7b40b3963f10..f541cfc3cb2d 100644
> --- a/mm/percpu.c
> +++ b/mm/percpu.c
> @@ -2244,6 +2244,35 @@ static void pcpu_balance_workfn(struct work_struct *work)
> mutex_unlock(&pcpu_alloc_mutex);
> }
>
> +/**
> + * alloc_size_percpu - the size of the dynamic percpu area
Can we name this pcpu_alloc_size(). A few other functions are
exposed under pcpu_* so it's a bit easier to keep track of.
> + * @ptr: pointer to the dynamic percpu area
> + *
> + * Return the size of the dynamic percpu area @ptr.
> + *
> + * RETURNS:
> + * The size of the dynamic percpu area.
> + *
> + * CONTEXT:
> + * Can be called from atomic context.
> + */
> +size_t alloc_size_percpu(void __percpu *ptr)
> +{
> + struct pcpu_chunk *chunk;
> + int bit_off, end;
> + void *addr;
> +
> + if (!ptr)
> + return 0;
> +
> + addr = __pcpu_ptr_to_addr(ptr);
> + /* No pcpu_lock here: ptr has not been freed, so chunk is still alive */
Now that percpu variables are floating around more commonly, I think we
or I need to add more validation guards so it's easier to
debug bogus/stale pointers. Potentially like a static_key or Kconfig so
that we take the lock and `test_bit()`.
> + chunk = pcpu_chunk_addr_search(addr);
> + bit_off = (addr - chunk->base_addr) / PCPU_MIN_ALLOC_SIZE;
> + end = find_next_bit(chunk->bound_map, pcpu_chunk_map_bits(chunk), bit_off + 1);
Nit: can you please reflow `bit_off + 1` to the next line. I know we
dropped the line requirement, but percpu.c almost completely still
follows it.
> + return (end - bit_off) * PCPU_MIN_ALLOC_SIZE;
> +}
> +
> /**
> * free_percpu - free percpu area
> * @ptr: pointer to area to free
> --
> 2.29.2
>
Thanks,
Dennis
next prev parent reply other threads:[~2023-10-08 22:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-07 13:51 [PATCH bpf-next 0/6] bpf: Fixes for per-cpu kptr Hou Tao
2023-10-07 13:51 ` [PATCH bpf-next 1/6] mm/percpu.c: introduce alloc_size_percpu() Hou Tao
2023-10-07 14:04 ` Andrew Morton
2023-10-08 2:47 ` Hou Tao
2023-10-08 22:32 ` Dennis Zhou [this message]
2023-10-11 6:30 ` Hou Tao
2023-10-07 13:51 ` [PATCH bpf-next 2/6] bpf: Re-enable unit_size checking for global per-cpu allocator Hou Tao
2023-10-09 16:51 ` Alexei Starovoitov
2023-10-07 13:51 ` [PATCH bpf-next 3/6] bpf: Use alloc_size_percpu() in bpf_mem_free{_rcu}() Hou Tao
2023-10-07 13:51 ` [PATCH bpf-next 4/6] bpf: Move the declaration of __bpf_obj_drop_impl() to internal.h Hou Tao
2023-10-09 16:28 ` Stanislav Fomichev
2023-10-11 6:31 ` Hou Tao
2023-10-09 16:56 ` Alexei Starovoitov
2023-10-11 6:40 ` Hou Tao
2023-10-07 13:51 ` [PATCH bpf-next 5/6] bpf: Use bpf_global_percpu_ma for per-cpu kptr in __bpf_obj_drop_impl() Hou Tao
2023-10-07 13:51 ` [PATCH bpf-next 6/6] selftests/bpf: Add more test cases for bpf memory allocator Hou Tao
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=ZSMt70tuBrHlI0Xa@snowbird \
--to=dennis@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=cl@linux.com \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=houtao1@huawei.com \
--cc=houtao@huaweicloud.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-mm@kvack.org \
--cc=martin.lau@linux.dev \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=tj@kernel.org \
--cc=yonghong.song@linux.dev \
/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.