All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Florian Lehner" <dev@der-flo.net>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next 2/2 v3] selftests/bpf: Test LINK_DETACH for perf link
Date: Fri, 01 May 2026 17:11:11 +0000	[thread overview]
Message-ID: <20260501171111.B2EE3C2BCC4@smtp.kernel.org> (raw)
In-Reply-To: <20260501160901.224134-3-dev@der-flo.net>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `test_perf_link_detach` test verification is brittle and likely to falsely pass, as a single call to `burn_cpu()` is too short to guarantee a perf event tick.
--

commit 80a1776d4374467cf1d037c1e22a1252e27c885c
Author: Florian Lehner <dev@der-flo.net>

selftests/bpf: Test LINK_DETACH for perf link

This commit adds a new test, test_perf_link_detach(), to verify the
BPF_LINK_DETACH syscall path for software perf events. It creates a link,
verifies execution, detaches it, and checks that the program is no longer
invoked.

> diff --git a/tools/testing/selftests/bpf/prog_tests/perf_link.c b/tools/testing/selftests/bpf/prog_tests/perf_link.c
> index 9e3a0d217af8..b75112c1b67d 100644
> --- a/tools/testing/selftests/bpf/prog_tests/perf_link.c
> +++ b/tools/testing/selftests/bpf/prog_tests/perf_link.c

[ ... ]

> +void test_perf_link_detach(void)
> +{
> +	struct test_perf_link *skel = NULL;
> +	int pfd = -1, link_fd = -1, err;
> +	int run_cnt_before, run_cnt_after;
> +	__u64 timeout_time_ns;

[ ... ]

> +	/* detach via BPF_LINK_DETACH - BPF program should no longer be executed */
> +	err = bpf_link_detach(link_fd);
> +	if (!ASSERT_OK(err, "link_detach"))
> +		goto cleanup;
> +
> +	/* make sure there are no stragglers */
> +	kern_sync_rcu();
> +
> +	run_cnt_before = skel->bss->run_cnt;
> +	burn_cpu();
> +	run_cnt_after = skel->bss->run_cnt;
> +
> +	ASSERT_EQ(run_cnt_before, run_cnt_after, "run_cnt_detached");

Is a single call to burn_cpu() sufficient to guarantee a perf event tick here?

The software CPU clock perf event is configured in perf_link_setup() to sample
at 1000 Hz, meaning it triggers approximately once every 1 millisecond of CPU
time.

The burn_cpu() function executes a fixed loop of 1,000,000 iterations. On
modern CPUs, this loop often takes significantly less than 1 millisecond to
complete.

Because a single burn_cpu() invocation takes less than the 1ms interval, is
it possible that no timer interrupt occurs during this window?

If so, run_cnt_after would equal run_cnt_before even if the detach operation
failed and the program was still attached, causing the test to falsely pass.
Could this be changed to use a time-based loop (similar to the initial
execution check) for several milliseconds to ensure correctness?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260501160901.224134-1-dev@der-flo.net?part=2

  reply	other threads:[~2026-05-01 17:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-01 16:08 [PATCH bpf-next 0/2 v3] bpf: Add LINK_DETACH for perf links Florian Lehner
2026-05-01 16:09 ` [PATCH bpf-next 1/2 v3] bpf: Add LINK_DETACH support for perf link Florian Lehner
2026-05-01 16:52   ` bot+bpf-ci
2026-05-01 16:59   ` sashiko-bot
2026-05-01 16:09 ` [PATCH bpf-next 2/2 v3] selftests/bpf: Test LINK_DETACH " Florian Lehner
2026-05-01 17:11   ` sashiko-bot [this message]
2026-05-03 13:14   ` Jiri Olsa

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=20260501171111.B2EE3C2BCC4@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=dev@der-flo.net \
    --cc=sashiko@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.