mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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 2/2] local_lock: do not put btf_type_tag on the lock guard type
Date: Mon,  9 Nov 2026 17:22:35 -0800	[thread overview]
Message-ID: <20261110012235.1024461-3-vineet.gupta@linux.dev> (raw)
In-Reply-To: <20261110012235.1024461-1-vineet.gupta@linux.dev>

local_lock.h applies __percpu the same way the per-cpu declarations do,
and hits the same problem as the previous patch:

	DEFINE_LOCK_GUARD_1(local_lock, local_lock_t __percpu,
			    local_lock(_T->lock),
			    local_unlock(_T->lock))

	local_lock.h:86:1: warning: ignoring attributes applied to
	'struct local_lock' after definition [-Wattributes]

which -Werror turns into a build failure, four times over: the same
pattern is repeated for local_lock_irq, local_lock_irqsave and
local_lock_nested_bh.

local_lock_t is a typedef of struct local_lock, and DEFINE_LOCK_GUARD_1()
hands its second argument to cleanup.h, which forms a typedef of it and a
guard struct holding a pointer to it. An x86 defconfig preprocesses the
line above to

	typedef local_lock_t __seg_gs
	__attribute__((btf_type_tag("percpu"))) lock_local_lock_t;

	typedef struct { local_lock_t __seg_gs
	__attribute__((btf_type_tag("percpu"))) *lock; } class_local_lock_t;

Both put the tag on local_lock_t, an aggregate: the first on a typedef of
it, the second on the pointee of the guard's member. Every variant of an
aggregate shares one DIE, so there is nowhere to record it, exactly as for
DECLARE_PER_CPU() of a struct. clang writes the annotation into DWARF
without complaint, but pahole does not translate it from that position,
so with today's toolchains it reaches BTF from neither compiler.

Use __percpu_var here too, which leaves

	typedef local_lock_t __seg_gs lock_local_lock_t;
	typedef struct { local_lock_t __seg_gs *lock; } class_local_lock_t;

Sparse keeps the __percpu address space, and the __releases() casts to
"local_lock_t __percpu **" further down are unchanged, so the pointer
spelling the tag exists for keeps it.

Unlike the per-cpu declarations this changes no BTF at all. A tag in that
position was never recorded, so there is nothing to remove, and the one
percpu TYPE_TAG that does reach a local_lock type comes from those casts,
which keep it. An x86 defconfig built with clang is identical with and
without this patch: 152551 BTF types and a 6828300 byte .BTF either way,
and .text is unchanged. The patch removes a GCC diagnostic and no more.

Signed-off-by: Vineet Gupta <vineet.gupta@linux.dev>
---
 include/linux/local_lock.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/linux/local_lock.h b/include/linux/local_lock.h
index b8830148a859..9d3d62e46007 100644
--- a/include/linux/local_lock.h
+++ b/include/linux/local_lock.h
@@ -83,13 +83,13 @@
 #define local_trylock_irqsave(lock, flags)			\
 	__local_trylock_irqsave(__this_cpu_local_lock(lock), flags)
 
-DEFINE_LOCK_GUARD_1(local_lock, local_lock_t __percpu,
+DEFINE_LOCK_GUARD_1(local_lock, local_lock_t __percpu_var,
 		    local_lock(_T->lock),
 		    local_unlock(_T->lock))
-DEFINE_LOCK_GUARD_1(local_lock_irq, local_lock_t __percpu,
+DEFINE_LOCK_GUARD_1(local_lock_irq, local_lock_t __percpu_var,
 		    local_lock_irq(_T->lock),
 		    local_unlock_irq(_T->lock))
-DEFINE_LOCK_GUARD_1(local_lock_irqsave, local_lock_t __percpu,
+DEFINE_LOCK_GUARD_1(local_lock_irqsave, local_lock_t __percpu_var,
 		    local_lock_irqsave(_T->lock, _T->flags),
 		    local_unlock_irqrestore(_T->lock, _T->flags),
 		    unsigned long flags)
@@ -100,7 +100,7 @@ DEFINE_LOCK_GUARD_1(local_lock_irqsave, local_lock_t __percpu,
 #define local_unlock_nested_bh(_lock)				\
 	__local_unlock_nested_bh(__this_cpu_local_lock(_lock))
 
-DEFINE_LOCK_GUARD_1(local_lock_nested_bh, local_lock_t __percpu,
+DEFINE_LOCK_GUARD_1(local_lock_nested_bh, local_lock_t __percpu_var,
 		    local_lock_nested_bh(_T->lock),
 		    local_unlock_nested_bh(_T->lock))
 
-- 
2.53.0-Meta


      parent reply	other threads:[~2026-11-10  1:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-10  1:22 [RFC PATCH 0/2] percpu, local_lock: drop btf_type_tag where no compiler records it Vineet Gupta
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 ` 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=20261110012235.1024461-3-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 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®