[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20221213183529.766630-2-nathan@kernel.org>
Date: Tue, 13 Dec 2022 11:35:28 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: Nick Desaulniers <ndesaulniers@...gle.com>,
Tom Rix <trix@...hat.com>, Nicolas Schier <nicolas@...sle.eu>,
Sami Tolvanen <samitolvanen@...gle.com>,
Vincent Donnefort <vdonnefort@...gle.com>,
linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
llvm@...ts.linux.dev, patches@...ts.linux.dev,
Nathan Chancellor <nathan@...nel.org>,
Daniel Jordan <daniel.m.jordan@...cle.com>,
Steffen Klassert <steffen.klassert@...unet.com>,
linux-crypto@...r.kernel.org
Subject: [PATCH v3 1/2] padata: Mark padata_work_init() as __ref
When building arm64 allmodconfig + ThinLTO with clang and a proposed
modpost update to account for -ffuncton-sections, the following warning
appears:
WARNING: modpost: vmlinux.o: section mismatch in reference: padata_work_init (section: .text.padata_work_init) -> padata_mt_helper (section: .init.text)
WARNING: modpost: vmlinux.o: section mismatch in reference: padata_work_init (section: .text.padata_work_init) -> padata_mt_helper (section: .init.text)
LLVM has optimized padata_work_init() to include the address of
padata_mt_helper() directly because it inlined the other call to
padata_work_init() with padata_parallel_worker(), meaning the remaining
uses of padata_work_init() use padata_mt_helper() as the work_fn
argument. This optimization causes modpost to complain since
padata_work_init() is not __init, whereas padata_mt_helper() is.
Since padata_work_init() is only called from __init code when
padata_mt_helper() is passed as the work_fn argument, mark
padata_work_init() as __ref, which makes it clear to modpost that this
scenario is okay.
Suggested-by: Daniel Jordan <daniel.m.jordan@...cle.com>
Signed-off-by: Nathan Chancellor <nathan@...nel.org>
---
Cc: Steffen Klassert <steffen.klassert@...unet.com>
Cc: Daniel Jordan <daniel.m.jordan@...cle.com>
Cc: linux-crypto@...r.kernel.org
---
kernel/padata.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/kernel/padata.c b/kernel/padata.c
index e5819bb8bd1d..d175cc000453 100644
--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -83,8 +83,16 @@ static struct padata_work *padata_work_alloc(void)
return pw;
}
-static void padata_work_init(struct padata_work *pw, work_func_t work_fn,
- void *data, int flags)
+/*
+ * This function is marked __ref because this function may be optimized in such
+ * a way that it directly refers to work_fn's address, which causes modpost to
+ * complain when work_fn is marked __init. This scenario was observed with clang
+ * LTO, where padata_work_init() was optimized to refer directly to
+ * padata_mt_helper() because the calls to padata_work_init() with other work_fn
+ * values were eliminated or inlined.
+ */
+static void __ref padata_work_init(struct padata_work *pw, work_func_t work_fn,
+ void *data, int flags)
{
if (flags & PADATA_WORK_ONSTACK)
INIT_WORK_ONSTACK(&pw->pw_work, work_fn);
--
2.39.0
Powered by blists - more mailing lists