From: Ihor Solodrai <ihor.solodrai@linux.dev>
To: Vineet Gupta <vineet.gupta@linux.dev>,
bpf@vger.kernel.org, andrii@kernel.org, ast@kernel.org,
daniel@iogearbox.net
Cc: eddyz87@gmail.com, memxor@gmail.com, martin.lau@linux.dev,
song@kernel.org, yonghong.song@linux.dev, jolsa@kernel.org,
emil@etsalapatis.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next v2] selftests/bpf: Fix linked_externs with bpf-gcc
Date: Mon, 28 Sep 2026 17:01:42 -0700 [thread overview]
Message-ID: <4e178583-b510-457f-94bc-e0e201698371@linux.dev> (raw)
In-Reply-To: <20260928231441.4037097-1-vineet.gupta@linux.dev>
On 2026-09-28 4:14 p.m., Vineet Gupta wrote:
> test_progs-bpf_gcc fails to build:
>
> prog_tests/linked_externs.c:17:23: error: 'struct linked_arena' has no
> member named 'arena'
>
> Several problems, all from bpf-gcc not supporting address_space(1).
>
> First, the arena variables are declared with __arena, but that macro is
> for pointers -- it marks the pointee address space. The one that carries
> placement is __arena_global:
>
> #if defined(__BPF_FEATURE_ADDR_SPACE_CAST) && !defined(BPF_ARENA_FORCE_ASM)
> #define __arena __attribute__((address_space(1))) __attribute__((btf_type_tag("arena")))
> #define __arena_global __attribute__((address_space(1)))
> #else
> #define __arena __attribute__((btf_type_tag("arena")))
> #define __arena_global SEC(".addr_space.1")
> #endif
>
> __BPF_FEATURE_ADDR_SPACE_CAST is a clang predefine. Under clang the two
> are interchangeable here, since address_space(1) both places the
> variable and is what btf_type_tag would have described. Under bpf-gcc
> __arena is only a BTF type tag, so the definitions land in .data, the
> arena map gets no initial value, and is_skel_data() in bpftool does not
> emit the typed arena member -- hence the build error. Note this is
> distinct from skel->maps.arena, which comes from SEC(".maps") and is
> always present.
>
> The extern declarations need __arena_global too. Without a section, gcc
> does not place an extern in any DATASEC, so it stays a free-floating
> extern VAR rather than an entry of .addr_space.1. test_relink() only
> walks that DATASEC:
>
> id = btf__find_by_name_kind(btf, sec_name, BTF_KIND_DATASEC);
> ...
> ASSERT_NEQ(btf_var(t)->linkage, BTF_VAR_GLOBAL_EXTERN, "var_resolved");
>
> so relink_arena would report OK under bpf-gcc whether or not the linker
> resolved anything -- it would not be testing the allocated-section path
> this test exists for.
>
> Second, placement alone is not enough to run the test. Dereferencing an
> arena global needs an addr_space_cast, which only clang emits:
>
> clang: bpf-gcc:
> r1 = 0x0 ll r1 = 0x0 ll
> r1 = addr_space_cast(r1, 0x0, 0x1) r2 = *(u64 *)(r1 + 0x0)
> r1 = *(u64 *)(r1 + 0x0)
>
> so the verifier sees a scalar and rejects the program:
>
> 4: (79) r2 = *(u64 *)(r1 +0)
> R1 invalid mem access 'scalar'
>
> Guard the program bodies and skip the skeleton subtest, as
> arena_atomics.c already does. The variables stay unconditional so the
> arena is still populated and the skeleton still has its member. The
> fallback bodies reference the externs without dereferencing them:
> 'used' is ignored on an extern, so an unreferenced one is dropped and
> .addr_space.1 loses it again.
>
> With this, bpf-gcc reports:
>
> #217/1 linked_externs/skel_arena:SKIP
> #217/2 linked_externs/relink_arena:OK
> #217/3 linked_externs/relink_maps:OK
>
> with b_val present in .addr_space.1 as linkage=extern, same as clang, so
> relink_arena covers the same path in both. clang still passes all three.
>
> Fixes: 34354db1b148 ("selftests/bpf: Add linked_externs test for externs in allocated sections")
> Signed-off-by: Vineet Gupta <vineet.gupta@linux.dev>
Tested-by: Ihor Solodrai <ihor.solodrai@linux.dev>
This fixes the current GCC BPF selftests build failure on CI:
https://github.com/kernel-patches/vmtest/actions/runs/36498905340/job/109187331070
nit: The commit message is kinda too long. If you'd like it to be read
by a human, try making it shorter :)
Thanks!
> [...]
next prev parent reply other threads:[~2026-09-29 0:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 23:14 [PATCH bpf-next v2] selftests/bpf: Fix linked_externs with bpf-gcc Vineet Gupta
2026-09-29 0:01 ` Ihor Solodrai [this message]
2026-09-29 0:26 ` Andrii Nakryiko
2026-09-29 0:30 ` patchwork-bot+netdevbpf
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=4e178583-b510-457f-94bc-e0e201698371@linux.dev \
--to=ihor.solodrai@linux.dev \
--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=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=song@kernel.org \
--cc=vineet.gupta@linux.dev \
--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.