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.

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

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

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

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