[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0575e8ab-7a70-48a4-b316-ef22fd8cece5@linux.dev>
Date: Mon, 26 Jan 2026 12:39:27 -0800
From: Martin KaFai Lau <martin.lau@...ux.dev>
To: Leon Hwang <leon.hwang@...ux.dev>
Cc: Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>,
Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>,
Yonghong Song <yonghong.song@...ux.dev>,
John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>,
Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>,
Jiri Olsa <jolsa@...nel.org>, Shuah Khan <shuah@...nel.org>,
linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org,
kernel-patches-bot@...com, bpf@...r.kernel.org
Subject: Re: [PATCH bpf-next] selftests/bpf: Harden cpu flags test for
lru_percpu_hash map
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.
Powered by blists - more mailing lists