From: Slava Imameev <slava.imameev@crowdstrike.com>
To: <ameryhung@gmail.com>
Cc: <alexei.starovoitov@gmail.com>, <andrii@kernel.org>,
<bpf@vger.kernel.org>, <daniel@iogearbox.net>,
<kernel-team@meta.com>, <kpsingh@kernel.org>,
<martin.lau@kernel.org>, <memxor@gmail.com>,
<netdev@vger.kernel.org>, <song@kernel.org>,
<yonghong.song@linux.dev>, <linux-open-source@crowdstrike.com>
Subject: Re: [PATCH v2 bpf-next 4/4] bpf: Replace bpf memory allocator with kmalloc_nolock() in local storage
Date: Fri, 10 Apr 2026 11:43:41 +1000 [thread overview]
Message-ID: <20260410014341.47043-1-slava.imameev@crowdstrike.com> (raw)
In-Reply-To: <20251114201329.3275875-5-ameryhung@gmail.com>
I found that this patch restricts task storage value allocation to
KMALLOC_MAX_CACHE_SIZE on any system regardless of CONFIG_PREEMPT_RT,
which is 8KB on many systems, as use_kmalloc_nolock is set to true
always for task storage by task_storage_map_alloc. Before this patch
there was no such restriction and task storage supported at least 64KB
allocation for value, restricted only by
BPF_LOCAL_STORAGE_MAX_VALUE_SIZE. Was this KMALLOC_MAX_CACHE_SIZE
restriction added deliberately by this patch?
next prev parent reply other threads:[~2026-04-10 1:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-14 20:13 [PATCH v2 bpf-next 0/4] Replace BPF memory allocator with kmalloc_nolock() in local storage Amery Hung
2025-11-14 20:13 ` [PATCH v2 bpf-next 1/4] bpf: Always charge/uncharge memory when allocating/unlinking storage elements Amery Hung
2025-11-17 18:25 ` Martin KaFai Lau
2025-11-14 20:13 ` [PATCH v2 bpf-next 2/4] bpf: Remove smap argument from bpf_selem_free() Amery Hung
2025-11-17 18:32 ` Martin KaFai Lau
2025-11-14 20:13 ` [PATCH v2 bpf-next 3/4] bpf: Save memory alloction info in bpf_local_storage Amery Hung
2025-11-17 18:36 ` Martin KaFai Lau
2025-11-14 20:13 ` [PATCH v2 bpf-next 4/4] bpf: Replace bpf memory allocator with kmalloc_nolock() in local storage Amery Hung
2025-11-15 2:01 ` Alexei Starovoitov
2025-11-17 19:21 ` Martin KaFai Lau
2025-11-17 20:37 ` Amery Hung
2025-11-17 23:36 ` Alexei Starovoitov
2025-11-17 23:46 ` Paul E. McKenney
2025-11-18 0:24 ` Amery Hung
2025-11-18 0:41 ` Paul E. McKenney
2026-04-10 1:43 ` Slava Imameev [this message]
2025-11-19 0:30 ` [PATCH v2 bpf-next 0/4] Replace BPF " patchwork-bot+netdevbpf
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=20260410014341.47043-1-slava.imameev@crowdstrike.com \
--to=slava.imameev@crowdstrike.com \
--cc=alexei.starovoitov@gmail.com \
--cc=ameryhung@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@meta.com \
--cc=kpsingh@kernel.org \
--cc=linux-open-source@crowdstrike.com \
--cc=martin.lau@kernel.org \
--cc=memxor@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=song@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox