From: Martin KaFai Lau <martin.lau@linux.dev>
To: Leon Hwang <leon.hwang@linux.dev>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>, Shuah Khan <shuah@kernel.org>,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-patches-bot@fb.com, bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next] selftests/bpf: Harden cpu flags test for lru_percpu_hash map
Date: Mon, 26 Jan 2026 12:39:27 -0800 [thread overview]
Message-ID: <0575e8ab-7a70-48a4-b316-ef22fd8cece5@linux.dev> (raw)
In-Reply-To: <20260119133417.19739-1-leon.hwang@linux.dev>
On 1/19/26 5:34 AM, Leon Hwang wrote:
> Harden the test against this behavior by provisioning sufficient spare
> elements. Set max_entries to 'nr_cpus * 2' and restrict the test to using
> the first nr_cpus entries, ensuring that updates do not spuriously trigger
> LRU eviction.
[ ... ]
@ -300,7 +307,7 @@ static void test_percpu_map_cpu_flag(enum
bpf_map_type map_type)
> if (!ASSERT_GT(nr_cpus, 0, "libbpf_num_possible_cpus"))
> return;
>
> - max_entries = nr_cpus + 1;
> + max_entries = nr_cpus * 2;
> keys = calloc(max_entries, key_sz);
Does it need to allocate "nr_cpus * 2" number of keys while only first
nr_cpus entries are used? This can be a followup if it's needed. Applied
to start getting signal from CI.
next prev parent reply other threads:[~2026-01-26 20:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-19 13:34 [PATCH bpf-next] selftests/bpf: Harden cpu flags test for lru_percpu_hash map Leon Hwang
2026-01-26 20:39 ` Martin KaFai Lau [this message]
2026-01-26 20:40 ` 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=0575e8ab-7a70-48a4-b316-ef22fd8cece5@linux.dev \
--to=martin.lau@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kernel-patches-bot@fb.com \
--cc=kpsingh@kernel.org \
--cc=leon.hwang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=sdf@fomichev.me \
--cc=shuah@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 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.