From: Vineet Gupta <vineet.gupta@linux.dev>
To: dennis@kernel.org, tj@kernel.org, cl@gentwo.org,
peterz@infradead.org, mingo@redhat.com, will@kernel.org,
boqun@kernel.org
Cc: longman@redhat.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
ast@kernel.org, andrii@kernel.org, daniel@iogearbox.net,
acme@kernel.org, yonghong.song@linux.dev, eddyz87@gmail.com,
martin.lau@linux.dev, nathan@kernel.org, ndesaulniers@google.com,
morbo@google.com, justinstitt@google.com, llvm@lists.linux.dev,
Vineet Gupta <vineet.gupta@linux.dev>
Subject: [RFC PATCH 0/2] percpu, local_lock: drop btf_type_tag where no compiler records it
Date: Mon, 9 Nov 2026 17:22:33 -0800 [thread overview]
Message-ID: <20261110012235.1024461-1-vineet.gupta@linux.dev> (raw)
Hi,
Currently PAHOLE_HAS_BTF_TAG is gated on CC_IS_CLANG and the goal is
to allow CC_IS_GCC. There are GCC fixes (PR128479, PR125991) in the
making [1] but despite all of them an x86 defconfig still emits ~40k
instances of spew like:
arch/x86/include/asm/processor.h:232:36: warning: ignoring attributes
applied to 'struct cpuinfo_x86' after definition [-Wattributes]
where one is enough to break a -Werror build.
Making GCC stop warning here was proposed as PR128480 and rejected:
the suggested answer was -Wno-attributes, which the kernel would not
accept just to suppress this noise.
And even if warnings were to be ignored, the build would still fail
with 33 hard errors from a separate GCC bug, PR128477,
include/linux/percpu-defs.h:216:45: error: initialization from
pointer to non-enclosed address space
These come from the same tag on the same declarations, so this series
removes them too.
The root cause is where the tag is applied. BTF_TYPE_TAG(percpu)
records that a pointer points to per-cpu memory, but two places apply
it where the thing qualified is an aggregate, which no compiler can
tag (GCC or clang): every variant of an aggregate shares one DIE,
so there is nowhere to put it.
- __PCPU_ATTRS(), so DECLARE_PER_CPU() and DEFINE_PER_CPU() put the tag
on the per-cpu variable's own type;
- the type argument of DEFINE_LOCK_GUARD_1() in local_lock.h, which
cleanup.h turns into "typedef _type lock_<name>_t".
Nothing reads a tag in either position. The verifier matches "percpu" in
btf_ctx_access() and in the member walk in btf_struct_walk(), and both
check btf_type_is_ptr() first, so it only ever sees the tag on a pointer.
The aggregate case is the only one that warns. Where the per-cpu variable
is a pointer there is no diagnostic, but the record is wrong: GCC puts
the tag on the pointee, so
static DEFINE_PER_CPU(struct bpf_hrtimer *, hrtimer_running);
comes out saying hrtimer_running is an ordinary pointer to per-cpu
memory, when in truth it lives in per-cpu memory and points at ordinary
memory. clang records no tag there at all.
The following two patches address this:
- 1/2 provides a new variant of __percpu, __percpu_var which elides
the btf tag. Switches __PCPU_ATTRS to use it.
- 2/2: Applies __percpu_var in local_lock code.
Binary impact, x86 defconfig built with clang: patch 1 drops 280 BTF types
(140 TYPE_TAG and the 140 pointers carrying them, none referenced) and 3360
bytes of .BTF, with .text unchanged. Patch 2 changes nothing at all.
[1] https://inbox.sourceware.org/gcc-patches/20261109213600.772524-1-vineet.gupta@linux.dev/
Vineet Gupta (2):
percpu: do not put btf_type_tag on per-cpu variable declarations
local_lock: do not put btf_type_tag on the lock guard type
include/linux/compiler_types.h | 8 ++++++++
include/linux/local_lock.h | 8 ++++----
include/linux/percpu-defs.h | 2 +-
3 files changed, 13 insertions(+), 5 deletions(-)
--
2.53.0-Meta
next reply other threads:[~2026-11-10 1:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 1:22 Vineet Gupta [this message]
2026-11-10 1:22 ` [RFC PATCH 1/2] percpu: do not put btf_type_tag on per-cpu variable declarations Vineet Gupta
2026-11-10 1:22 ` [RFC PATCH 2/2] local_lock: do not put btf_type_tag on the lock guard type Vineet Gupta
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=20261110012235.1024461-1-vineet.gupta@linux.dev \
--to=vineet.gupta@linux.dev \
--cc=acme@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=boqun@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=cl@gentwo.org \
--cc=daniel@iogearbox.net \
--cc=dennis@kernel.org \
--cc=eddyz87@gmail.com \
--cc=justinstitt@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=llvm@lists.linux.dev \
--cc=longman@redhat.com \
--cc=martin.lau@linux.dev \
--cc=mingo@redhat.com \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=peterz@infradead.org \
--cc=tj@kernel.org \
--cc=will@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.