All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Yun Lu" <luyun_611@163.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 3/8] selftests/bpf: Check task work value membership
Date: Fri, 06 Nov 2026 10:56:02 +0000	[thread overview]
Message-ID: <sashiko-outbox-201252@kernel.org> (raw)
In-Reply-To: <20261106095747.471718-4-luyun_611@163.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] selftests/bpf: LRU eviction on CPU migration in open_test()
--

commit a48c230ac453ac2d2db53442d38749169b051723
Author: Yun Lu <luyun@kylinos.cn>

selftests/bpf: Check task work value membership

This commit adds BPF selftests verifying map value membership checks when
scheduling task_work across deletion, replacement, reinsertion, in-place
updates, and map user-reference drops.

> diff --git a/tools/testing/selftests/bpf/prog_tests/task_work_membership.c b/tools/testing/selftests/bpf/prog_tests/task_work_membership.c
> new file mode 100644
> index 0000000000000..0f5cdef3a24c7
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/task_work_membership.c
> @@ -0,0 +1,392 @@

[ ... ]

> +static struct task_work_membership *open_test(enum bpf_map_type type, __u32 flags,
> +					      bool use_signal)
> +{
> +	struct task_work_membership *skel;
> +	int err;
> +
> +	skel = task_work_membership__open();
> +	if (!ASSERT_OK_PTR(skel, "open"))
> +		return NULL;
> +	err = bpf_map__set_type(skel->maps.values, type);
> +	if (!ASSERT_OK(err, "map_type"))
> +		goto fail;
> +	err = bpf_map__set_map_flags(skel->maps.values, flags);
> +	if (!ASSERT_OK(err, "map_flags"))
> +		goto fail;
> +	/* A full LRU map can evict the target while obtaining a candidate. */
> +	if (type == BPF_MAP_TYPE_LRU_HASH) {
> +		err = bpf_map__set_max_entries(skel->maps.values, 2);
> +		if (!ASSERT_OK(err, "map_max_entries"))
> +			goto fail;
> +	}

[ ... ]

> +static void retired_value(enum bpf_map_type type, __u32 flags, bool use_signal,
> +			  bool replace)
> +{
> +	struct task_work_membership *skel;
> +	struct bpf_program *mutate;
> +	bool ok;
> +	int i;
> +
> +	skel = open_test(type, flags, use_signal);
> +	if (!skel)
> +		return;
> +	mutate = replace ? skel->progs.update_then_schedule :
> +			   skel->progs.delete_then_schedule;
> +	if (!insert_value(skel))
> +		goto out;
> +
> +	for (i = 0; i < REUSE_ROUNDS; i++) {
> +		/* Later rounds start with a ctx left by the live schedule below. */
> +		ok = run_prog(mutate, -ENOENT);
> +		if (replace)
> +			fprintf(stderr,
> +				"replace address map_type=%d old=%#llx new=%#llx\n",
> +				(int)type,
> +				(unsigned long long)skel->bss->old_value,
> +				(unsigned long long)skel->bss->new_value);
> +		if (!ok ||
> +		    !ASSERT_OK(skel->bss->mutation_err, "mutation") ||
> +		    !ASSERT_EQ(completed(skel), i, "retired_not_called"))
> +			goto out;

[Severity: Medium]
Can setting max_entries to 2 for BPF_MAP_TYPE_LRU_HASH still evict the live
entry in update_then_schedule() if the test thread migrates between CPUs
across iterations of retired_value()?

With max_entries = 2, bpf_common_lru_populate() allocates only two nodes (N1
and N2) on the global free list.  When N1 is inserted on CPU A, it is placed
on CPU A's per-CPU pending_list with N1->cpu = A.  If the unpinned test
thread sleeps in wait_completed() and migrates to CPU B for a replacement
round, prealloc_lru_pop() pops N2 from the global free list onto CPU B's
pending_list, and htab_lru_push_free() moves the replaced N1 from CPU A's
pending_list onto CPU A's per-CPU free_llist.

On the next round of update_then_schedule() on CPU B, CPU B's local
free_llist and the global free list are both empty.  Before stealing from CPU
A's free_llist, bpf_common_lru_pop_free() calls
bpf_lru_list_pop_free_to_local(), which flushes the live N2 from CPU B's
pending_list and shrinks the global list, evicting key 0 from the hash table.
htab_lru_map_update_elem() then fails its BPF_EXIST check with -ENOENT,
setting mutation_err = -ENOENT and failing the "mutation" assertion in
lru_replace_resume and lru_replace_signal.

Using BPF_F_NO_COMMON_LRU with a sufficient max_entries, or pinning the test
thread to a single CPU, would avoid stranding the spare node on a remote CPU.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261106095747.471718-1-luyun_611@163.com?part=3

  parent reply	other threads:[~2026-11-06 10:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06  9:57 [PATCH bpf-next v2 0/8] bpf: Fix async callback use-after-free on map deletion Yun Lu
2026-11-06  9:57 ` [PATCH bpf-next v2 1/8] bpf: Mark task work FREED before detaching it Yun Lu
2026-11-06  9:57 ` [PATCH bpf-next v2 2/8] bpf: Check task work value membership before scheduling Yun Lu
2026-11-06  9:57 ` [PATCH bpf-next v2 3/8] selftests/bpf: Check task work value membership Yun Lu
2026-11-06 10:31   ` bot+bpf-ci
2026-11-06 10:56   ` sashiko-bot [this message]
2026-11-06  9:57 ` [PATCH bpf-next v2 4/8] bpf: Order async callback admission and cancellation Yun Lu
2026-11-06  9:57 ` [PATCH bpf-next v2 5/8] bpf: Check bpf_wq value membership before use Yun Lu
2026-11-06  9:57 ` [PATCH bpf-next v2 6/8] selftests/bpf: Check bpf_wq value membership Yun Lu
2026-11-06 10:31   ` bot+bpf-ci
2026-11-06 11:26   ` sashiko-bot
2026-11-06  9:57 ` [PATCH bpf-next v2 7/8] bpf: Check bpf_timer value membership before use Yun Lu
2026-11-06 10:31   ` bot+bpf-ci
2026-11-06  9:57 ` [PATCH bpf-next v2 8/8] selftests/bpf: Check bpf_timer value membership Yun Lu
2026-11-06 10:31   ` bot+bpf-ci
2026-11-06 11:51   ` sashiko-bot
2026-11-06 17:16 ` [PATCH bpf-next v2 0/8] bpf: Fix async callback use-after-free on map deletion Alexei Starovoitov
2026-11-09  9:50   ` luyun

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=sashiko-outbox-201252@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=luyun_611@163.com \
    --cc=sashiko-reviews@lists.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.