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 <[email protected]> > >> > >> 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
