From: Jordan R Abrahams-Whitehead <ajordanr@google.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
Jordan R Abrahams-Whitehead <ajordanr@google.com>,
Eric Dumazet <edumazet@google.com>
Subject: [PATCH] Mark list_add and __list_add as __always_inline
Date: Fri, 31 Jul 2026 20:15:19 +0000 [thread overview]
Message-ID: <20260731-always-inline-list-add-v1-1-d29f54ce5477@google.com> (raw)
This commit resolves an issue where modpost section
verification fails due to section mismatches between list_add
and its callers.
At present, list_add (and its internal __list_add) are called from
both .text and .init code sections. Since inlining can vary per call
site, list_add can be 4 different states:
list_add in text with arguments to non-.init.data values
list_add in init with arguments to static .init.data values
list_add in init with arguments to non-.init.data values
list_add in text with arguments to static .init.data values
It is last instance that ends up causing the section mismatch caused by
constant propagation of the address of static libs inside the `dir_add`
as seen below (with the dir_list being defined statically in
initramfs.c, resting in .init.data).
WARNING: modpost: vmlinux.o: section mismatch in reference: __list_add
(section: .text.unlikely.) -> dir_list (section: .init.data)
Because of these section matching requirements, semantically,
__list_add and list_add MUST be inlined. This will then ensure
callers inside .init will receive a list_add that exists and refers
to only .init data, and list_add code in .text sections will only refer
to non-init data.
This issue manifests predominently in AutoFDO with clang, which is very
hesitant to inline cold functions such as list_add even when marked
`inline`. Marking them as `__always_inline` therefore matches the
existing semantic constraints imposed by modpost's section mismatch
checks.
Closes: https://github.com/ClangBuiltLinux/linux/issues/2173
Signed-off-by: Jordan R Abrahams-Whitehead <ajordanr@google.com>
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Suggested-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/all/CANn89iJVQe=wedLheJmjZjOTJsWHijT0jZs=iRxKssJZbjAxHw@mail.gmail.com/
---
include/linux/list.h | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/include/linux/list.h b/include/linux/list.h
index 09d979976b3b..59f8aa0905d3 100644
--- a/include/linux/list.h
+++ b/include/linux/list.h
@@ -150,10 +150,13 @@ static inline bool __list_del_entry_valid(struct list_head *entry)
*
* This is only for internal list manipulation where we know
* the prev/next entries already!
+ *
+ * Must be inlined to ensure it can be safely called
+ * with initdata arguments.
*/
-static inline void __list_add(struct list_head *new,
- struct list_head *prev,
- struct list_head *next)
+static __always_inline void __list_add(struct list_head *new,
+ struct list_head *prev,
+ struct list_head *next)
{
if (!__list_add_valid(new, prev, next))
return;
@@ -171,8 +174,12 @@ static inline void __list_add(struct list_head *new,
*
* Insert a new entry after the specified head.
* This is good for implementing stacks.
+ *
+ * Must be inlined to ensure it can be safely called
+ * with initdata arguments.
*/
-static inline void list_add(struct list_head *new, struct list_head *head)
+static __always_inline void list_add(struct list_head *new,
+ struct list_head *head)
{
__list_add(new, head, head->next);
}
---
base-commit: fc46aed51f6280801f43a2cf4b5060cc33b572f9
change-id: 20260730-always-inline-list-add-363639606e26
Best regards,
--
Jordan R Abrahams-Whitehead <ajordanr@google.com>
next reply other threads:[~2026-07-31 20:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 20:15 Jordan R Abrahams-Whitehead [this message]
2026-07-31 20:29 ` [PATCH] Mark list_add and __list_add as __always_inline Nick Desaulniers
2026-07-31 20:30 ` Nick Desaulniers
2026-07-31 20:36 ` Nick Desaulniers
2026-07-31 20:53 ` Jordan Abrahams-Whitehead
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=20260731-always-inline-list-add-v1-1-d29f54ce5477@google.com \
--to=ajordanr@google.com \
--cc=akpm@linux-foundation.org \
--cc=edumazet@google.com \
--cc=justinstitt@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
/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;
as well as URLs for NNTP newsgroup(s).