mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: bot+bpf-ci@kernel.org
To: xukuohai@huaweicloud.com,bpf@vger.kernel.org,linux-kernel@vger.kernel.org
Cc: ast@kernel.org,daniel@iogearbox.net,andrii@kernel.org,eddyz87@gmail.com,memxor@gmail.com,emil@etsalapatis.com,yonghong.song@linux.dev,ast@kernel.org,andrii@kernel.org,daniel@iogearbox.net,martin.lau@kernel.org,eddyz87@gmail.com,yonghong.song@linux.dev,mason@kernel.org,ihor.solodrai@linux.dev
Subject: Re: [PATCH bpf-next 16/16] selftests/bpf: Add test for arena percpu bounds
Date: Tue, 20 Oct 2026 14:17:08 +0000 (UTC)	[thread overview]
Message-ID: <45632128dde3ab61514bf0db311766b2113e01b63bdbd37c04f4a8b2de6c985c@mail.kernel.org> (raw)
In-Reply-To: <ad35a4e7b9ff044a63d7903ae6509c68ea05d6d5.1792503001.git.xukuohai@huawei.com>

[-- Attachment #1: Type: text/plain, Size: 3811 bytes --]

> selftests/bpf: Add test for arena percpu bounds

TL;DR: Nits only in the arena percpu bounds selftest: a redundant insns[2].off
= 0 assignment, and the repeated bpf_prog_load and log-check code could share
a helper.

> diff --git a/tools/testing/selftests/bpf/prog_tests/arena_percpu.c b/tools/testing/selftests/bpf/prog_tests/arena_percpu.c
> --- a/tools/testing/selftests/bpf/prog_tests/arena_percpu.c
> +++ b/tools/testing/selftests/bpf/prog_tests/arena_percpu.c

[ ... ]

> +/* check out of range pseudo instructions and accesses */
> +static void test_arena_percpu_percpu_bounds(void)
> +{

[ ... ]

> +	/* a reference at the start of the chunk loads */
> +	insns[1].imm = page_sz;
> +	prog_fd = bpf_prog_load(BPF_PROG_TYPE_RAW_TRACEPOINT,
> +				"arena_percpu_ref", "GPL", insns,
> +				ARRAY_SIZE(insns), &prog_opts);
> +	if (!ASSERT_GE(prog_fd, 0, "in_range_load"))
> +		goto out;
> +	close(prog_fd);
> +
> +	/* the first u64 below the chunk and one past its end are rejected */
> +	bad_offs[0] = page_sz - 8;
> +	bad_offs[1] = page_sz + page_sz;
> +
> +	for (i = 0; i < ARRAY_SIZE(bad_offs); i++) {
> +		insns[1].imm = bad_offs[i];
> +		prog_fd = bpf_prog_load(BPF_PROG_TYPE_RAW_TRACEPOINT,
> +					"arena_percpu_ref", "GPL", insns,
> +					ARRAY_SIZE(insns), &prog_opts);
> +		if (!ASSERT_LT(prog_fd, 0, "out_of_range_load"))
> +			close(prog_fd);
> +		snprintf(expected, sizeof(expected),
> +			 "per-cpu arena reference at offset %u "
> +			 "outside cpu 0's chunk", bad_offs[i]);
> +		ASSERT_HAS_SUBSTR(log_buf, expected, "out_of_range_log");
> +	}
> +
> +	/* the last u64 of the chunk is in range and loads */
> +	insns[1].imm = page_sz + page_sz - 8;
> +	insns[2].off = 0;

This isn't a bug, but is this insns[2].off = 0 assignment needed?  The field
is still 0 from the initializer at this point.

> +	prog_fd = bpf_prog_load(BPF_PROG_TYPE_RAW_TRACEPOINT,
> +				"arena_percpu_ref", "GPL", insns,
> +				ARRAY_SIZE(insns), &prog_opts);
> +	if (!ASSERT_GE(prog_fd, 0, "last_u64_load"))
> +		goto out;
> +	close(prog_fd);
> +
> +	/* one u64 past the chunk end is rejected */
> +	insns[2].off = 8;
> +	prog_fd = bpf_prog_load(BPF_PROG_TYPE_RAW_TRACEPOINT,
> +				"arena_percpu_ref", "GPL", insns,
> +				ARRAY_SIZE(insns), &prog_opts);
> +	if (!ASSERT_LT(prog_fd, 0, "out_of_range_access"))
> +		close(prog_fd);
> +	snprintf(expected, sizeof(expected),
> +		 "per-cpu arena access at offset %d size 8 "
> +		 "outside cpu 0's chunk", (int)page_sz);
> +	ASSERT_HAS_SUBSTR(log_buf, expected, "out_of_range_access_log");
> +
> +	/* an access below the chunk start is rejected */
> +	insns[1].imm = page_sz;
> +	insns[2].off = -8;
> +	prog_fd = bpf_prog_load(BPF_PROG_TYPE_RAW_TRACEPOINT,
> +				"arena_percpu_ref", "GPL", insns,
> +				ARRAY_SIZE(insns), &prog_opts);
> +	if (!ASSERT_LT(prog_fd, 0, "below_chunk_access"))
> +		close(prog_fd);
> +	snprintf(expected, sizeof(expected),
> +		 "per-cpu arena access at offset -8 size 8 "
> +		 "outside cpu 0's chunk");
> +	ASSERT_HAS_SUBSTR(log_buf, expected, "below_chunk_access_log");

This isn't a bug, but could the five identical bpf_prog_load() calls and the
repeated reject/log checks share a small helper?

Only insns[1].imm and insns[2].off differ between the cases, and the
ASSERT_LT + close, snprintf into expected, ASSERT_HAS_SUBSTR sequence is
repeated three times.

A helper taking the reference offset and the access offset, and returning
the prog fd or checking the expected log, would make each case a single
line, like run_on_cpu() and check_percpu_value() do elsewhere in this file.

[ ... ]


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/39434884362

  reply	other threads:[~2026-10-20 14:17 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-20 13:22 [PATCH bpf-next 00/16] Add percpu variable support for bpf arena Xu Kuohai
2026-10-20 13:22 ` [PATCH bpf-next 01/16] libbpf: Collect arena percpu data section Xu Kuohai
2026-10-20 14:17   ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 02/16] libbpf: Create arena percpu chunk from the arena percpu ELF section Xu Kuohai
2026-10-20 14:17   ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 03/16] libbpf: Place the percpu chunks in the bpf arena Xu Kuohai
2026-10-20 13:22 ` [PATCH bpf-next 04/16] libbpf: Copy the percpu chunks into " Xu Kuohai
2026-10-20 14:17   ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 05/16] libbpf: Add the arena percpu chunk attribute to map creation options Xu Kuohai
2026-10-20 14:17   ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 06/16] libbpf: Relocate arena percpu access instructions Xu Kuohai
2026-10-20 14:29   ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 07/16] libbpf: Add arena percpu feature probe Xu Kuohai
2026-10-20 14:17   ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 08/16] bpf: Extend syscall to accept arena percpu information Xu Kuohai
2026-10-20 14:17   ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 09/16] bpf: Teach verifier about arena percpu instructions Xu Kuohai
2026-10-20 14:29   ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 10/16] bpf, x86: Add support for arena percpu Xu Kuohai
2026-10-20 13:22 ` [PATCH bpf-next 11/16] bpf, arm64: " Xu Kuohai
2026-10-20 14:17   ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 12/16] libbpf: Introduce arena percpu helpers for user space Xu Kuohai
2026-10-20 14:17   ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 13/16] bpftool: Emit the arena percpu datasec into skeleton Xu Kuohai
2026-10-20 13:22 ` [PATCH bpf-next 14/16] selftests/bpf: Add test for arena percpu-only object Xu Kuohai
2026-10-20 14:17   ` bot+bpf-ci
2026-10-20 13:23 ` [PATCH bpf-next 15/16] selftests/bpf: Add test for mixed arena percpu object Xu Kuohai
2026-10-20 13:23 ` [PATCH bpf-next 16/16] selftests/bpf: Add test for arena percpu bounds Xu Kuohai
2026-10-20 14:17   ` bot+bpf-ci [this message]
2026-10-20 14:47 ` [PATCH bpf-next 00/16] Add percpu variable support for bpf arena Alexei Starovoitov

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=45632128dde3ab61514bf0db311766b2113e01b63bdbd37c04f4a8b2de6c985c@mail.kernel.org \
    --to=bot+bpf-ci@kernel.org \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=emil@etsalapatis.com \
    --cc=ihor.solodrai@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@kernel.org \
    --cc=mason@kernel.org \
    --cc=memxor@gmail.com \
    --cc=xukuohai@huaweicloud.com \
    --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

all inboxes | Powered by JetHome®