From: Vineet Gupta <vineet.gupta@linux.dev>
To: bot+bpf-ci@kernel.org, bpf@vger.kernel.org
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
x86@kernel.org, stable@vger.kernel.org, martin.lau@kernel.org,
eddyz87@gmail.com, yonghong.song@linux.dev, clm@meta.com,
ihor.solodrai@linux.dev
Subject: Re: [PATCH bpf v2 2/2] selftests/bpf: Check per-CPU address resolution per register
Date: Fri, 14 Aug 2026 14:51:54 -0700 [thread overview]
Message-ID: <c2650d12-784f-4f74-a520-ea97e4cb548c@linux.dev> (raw)
In-Reply-To: <7276efcb565f80eed9a05dd364570b432a68ba5d980d9d1676bf620501f10040@mail.kernel.org>
On 8/14/26 2:20 PM, bot+bpf-ci@kernel.org wrote:
>> diff --git a/tools/testing/selftests/bpf/progs/verifier_percpu_addr.c b/tools/testing/selftests/bpf/progs/verifier_percpu_addr.c
>> new file mode 100644
>> index 000000000000..962faea8ef90
>> --- /dev/null
>> +++ b/tools/testing/selftests/bpf/progs/verifier_percpu_addr.c
>> @@ -0,0 +1,114 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +#include <vmlinux.h>
>> +#include <bpf/bpf_helpers.h>
>> +#include "bpf_misc.h"
>> +
>> +int percpu_data SEC(".percpu");
>> +
>> +#if defined(__TARGET_ARCH_x86)
>> +
>> +/*
>> + * An ld_imm64 of a per-CPU map value is followed by a mov_percpu_addr that
>> + * reuses the same register, so the register the address lands in decides how
>> + * the JIT encodes the add. On x86 R5, R7, R8 and R9 are the extended
>> + * registers, whose high bit needs REX.R because the destination sits in
>> + * ModRM.reg. Check one program per extended register, since getting the
>> + * prefix wrong resolves the address into whichever register shares the low
>> + * three bits instead.
>> + */
>> +
>> +SEC("raw_tp")
>> +__description("per-CPU address into r5")
>> +__success
>> +__arch_x86_64
>> +__jited(" addq %gs:{{.*}}, %r8")
>> +__naked void percpu_addr_into_r5(void)
>> +{
>> + asm volatile (" \
>> + r5 = %[percpu_data] ll; \
>> + r0 = *(u32 *)(r5 + 0); \
>> + exit; \
>> +" :
>> + : __imm_addr(percpu_data)
>> + : __clobber_all);
>> +}
> This isn't a bug, but would it be tidier to move the percpu_data
> declaration inside the __TARGET_ARCH_x86 block?
>
> Currently percpu_data is declared above the arch guard, but its only
> readers (percpu_addr_into_r1/r5/r7/r8/r9) are inside the guard:
>
> +int percpu_data SEC(".percpu");
> +
> +#if defined(__TARGET_ARCH_x86)
> +
> +/* ... test functions using percpu_data ... */
>
> On every other target the object still carries a .percpu section, so
> libbpf still creates an unused percpu data map for it.
That's a good point, will address this in v3
Thx,
-Vineet
>
> Comparable files in the same directory keep objects used only by guarded
> programs inside the guard. verifier_private_stack.c declares its 'struct
> elem' and 'array SEC(".maps")' after the '#if defined(__TARGET_ARCH_x86)
> || defined(__TARGET_ARCH_arm64)' guard, and verifier_ldsx.c declares its
> 'arena SEC(".maps")' map inside its arch guard.
>
>
> ---
> 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/31839526403
prev parent reply other threads:[~2026-08-14 21:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 20:32 [PATCH bpf v2 0/2] bpf, x86: fix per-CPU address resolution into an extended register Vineet Gupta
2026-08-14 20:32 ` [PATCH bpf v2 1/2] bpf, x86: Fix " Vineet Gupta
2026-08-14 20:44 ` Eduard Zingerman
2026-08-14 21:20 ` bot+bpf-ci
2026-08-14 21:30 ` Vineet Gupta
2026-08-14 20:32 ` [PATCH bpf v2 2/2] selftests/bpf: Check per-CPU address resolution per register Vineet Gupta
2026-08-14 20:49 ` Eduard Zingerman
2026-08-14 21:20 ` bot+bpf-ci
2026-08-14 21:51 ` Vineet Gupta [this message]
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=c2650d12-784f-4f74-a520-ea97e4cb548c@linux.dev \
--to=vineet.gupta@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bot+bpf-ci@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=clm@meta.com \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=ihor.solodrai@linux.dev \
--cc=martin.lau@kernel.org \
--cc=stable@vger.kernel.org \
--cc=x86@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.