* Re: [PATCH] init.h: discard exitcall symbols early [not found] <20260331142846.3187706-1-arnd@kernel.org> @ 2026-03-31 14:56 ` Petr Mladek 2026-03-31 15:01 ` Arnd Bergmann 0 siblings, 1 reply; 3+ messages in thread From: Petr Mladek @ 2026-03-31 14:56 UTC (permalink / raw) To: Arnd Bergmann Cc: Andrew Morton, Nathan Chancellor, Nicolas Schier, linux-kbuild, Andy Shevchenko, Dmitry Torokhov, Arnd Bergmann, Kees Cook, Marco Elver, Peter Zijlstra (Intel), Josh Poimboeuf, Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen, Aaron Tomlin, linux-modules, linux-kernel Adding module loader maintainers into Cc to make them aware of this change. On Tue 2026-03-31 16:28:38, Arnd Bergmann wrote: > From: Arnd Bergmann <arnd@arndb.de> > > Any __exitcall() and built-in module_exit() handler is marked as __used, > which leads to the code being included in the object file and later > discarded at link time. Is this safe for dynamically loaded modules? Honestly, I am not sure what is the exact efect of this change. The dynamically loadded modules just came to my mind... Best Regards, Petr > As far as I can tell, this was originally added at the same time > as initcalls were marked the same way, to prevent them from getting > dropped with gcc-3.4, but it was never actaully necessary to keep exit > functions around. > > Mark them as __maybe_unused instead, which lets the compiler treat > the exitcalls as entirely unused, and make better decisions about > dropping specializing static functions called from these. > > Link: https://lore.kernel.org/all/acruxMNdnUlyRHiy@google.com/ > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > include/linux/init.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux/init.h b/include/linux/init.h > index 5db55c660124..ad5c19763034 100644 > --- a/include/linux/init.h > +++ b/include/linux/init.h > @@ -47,7 +47,7 @@ > #define __initdata __section(".init.data") > #define __initconst __section(".init.rodata") > #define __exitdata __section(".exit.data") > -#define __exit_call __used __section(".exitcall.exit") > +#define __exit_call __maybe_unused __section(".exitcall.exit") > > /* > * modpost check for section mismatches during the kernel build. > -- > 2.39.5 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] init.h: discard exitcall symbols early 2026-03-31 14:56 ` [PATCH] init.h: discard exitcall symbols early Petr Mladek @ 2026-03-31 15:01 ` Arnd Bergmann 2026-03-31 15:35 ` Petr Mladek 0 siblings, 1 reply; 3+ messages in thread From: Arnd Bergmann @ 2026-03-31 15:01 UTC (permalink / raw) To: Petr Mladek, Arnd Bergmann Cc: Andrew Morton, Nathan Chancellor, Nicolas Schier, linux-kbuild, Andy Shevchenko, Dmitry Torokhov, Kees Cook, Marco Elver, Peter Zijlstra, Josh Poimboeuf, Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen, Aaron Tomlin, linux-modules, linux-kernel On Tue, Mar 31, 2026, at 16:56, Petr Mladek wrote: > Adding module loader maintainers into Cc to make them aware of this > change. > > On Tue 2026-03-31 16:28:38, Arnd Bergmann wrote: >> From: Arnd Bergmann <arnd@arndb.de> >> >> Any __exitcall() and built-in module_exit() handler is marked as __used, >> which leads to the code being included in the object file and later >> discarded at link time. > > Is this safe for dynamically loaded modules? > > Honestly, I am not sure what is the exact efect of this change. > The dynamically loadded modules just came to my mind... In a loadable module, using __exitcall() directly already discards the function at link time, so there is no difference from built-in code. Actually using __exitcall() here is a mistake regardless of my patch. Using module_exit() in a loadable module still behaves as before, this uses a different macro, which already has __maybe_unused: #define module_exit(exitfn) \ static inline exitcall_t __maybe_unused __exittest(void) \ { return exitfn; } \ void cleanup_module(void) __copy(exitfn) \ __attribute__((alias(#exitfn))); \ ___ADDRESSABLE(cleanup_module, __exitdata); so this is also unchanged. Arnd ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] init.h: discard exitcall symbols early 2026-03-31 15:01 ` Arnd Bergmann @ 2026-03-31 15:35 ` Petr Mladek 0 siblings, 0 replies; 3+ messages in thread From: Petr Mladek @ 2026-03-31 15:35 UTC (permalink / raw) To: Arnd Bergmann Cc: Arnd Bergmann, Andrew Morton, Nathan Chancellor, Nicolas Schier, linux-kbuild, Andy Shevchenko, Dmitry Torokhov, Kees Cook, Marco Elver, Peter Zijlstra, Josh Poimboeuf, Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen, Aaron Tomlin, linux-modules, linux-kernel On Tue 2026-03-31 17:01:20, Arnd Bergmann wrote: > On Tue, Mar 31, 2026, at 16:56, Petr Mladek wrote: > > Adding module loader maintainers into Cc to make them aware of this > > change. > > > > On Tue 2026-03-31 16:28:38, Arnd Bergmann wrote: > >> From: Arnd Bergmann <arnd@arndb.de> > >> > >> Any __exitcall() and built-in module_exit() handler is marked as __used, > >> which leads to the code being included in the object file and later > >> discarded at link time. > > > > Is this safe for dynamically loaded modules? > > > > Honestly, I am not sure what is the exact efect of this change. > > The dynamically loadded modules just came to my mind... > > In a loadable module, using __exitcall() directly already discards > the function at link time, so there is no difference from built-in > code. Actually using __exitcall() here is a mistake regardless > of my patch. > > Using module_exit() in a loadable module still behaves as before, > this uses a different macro, which already has __maybe_unused: > > #define module_exit(exitfn) \ > static inline exitcall_t __maybe_unused __exittest(void) \ > { return exitfn; } \ > void cleanup_module(void) __copy(exitfn) \ > __attribute__((alias(#exitfn))); \ > ___ADDRESSABLE(cleanup_module, __exitdata); > > so this is also unchanged. I see, I was confused because cscope pointed me to: /** * module_exit() - driver exit entry point * @x: function to be run when driver is removed * * module_exit() will wrap the driver clean-up code * with cleanup_module() when used with rmmod when * the driver is a module. If the driver is statically * compiled into the kernel, module_exit() has no effect. * There can only be one per module. */ #define module_exit(x) __exitcall(x); and I missed that it was the variant for the built-in modules. Best Regards, Petr ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-03-31 15:35 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20260331142846.3187706-1-arnd@kernel.org>
2026-03-31 14:56 ` [PATCH] init.h: discard exitcall symbols early Petr Mladek
2026-03-31 15:01 ` Arnd Bergmann
2026-03-31 15:35 ` Petr Mladek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox