On 13/10/2025 18.26, Lucas De Marchi wrote: > The -EEXIST errno is reserved by the module loading functionality. When > userspace calls [f]init_module(), it expects a -EEXIST to mean that the > module is already loaded in the kernel. If module_init() returns it, > that is not true anymore. > > Add a warning and override the return code to workaround modules > currently returning the wrong code. It's expected that they eventually > migrate to a better suited error.
I've been following the thread (and apologies for the delay) and reviewing the patches, and I do not believe we should push this workaround. While this "fixes" the bug reported, it also hides the real problem and drivers will continue misusing EEXIST at module initialization. >From the bug report thread, I agree with Christophe's suggestion that nf_conntrack_helpers_register() should return EBUSY instead of EEXIST. This would fix the root cause for this particular module and will allow others to change their module behavior, if we also follow up with proper documentation about EEXIST. > > Closes: https://lore.kernel.org/all/[email protected]/ > Signed-off-by: Lucas De Marchi <[email protected]> > --- > kernel/module/main.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/kernel/module/main.c b/kernel/module/main.c > index c66b261849362..74ff87b13c517 100644 > --- a/kernel/module/main.c > +++ b/kernel/module/main.c > @@ -3038,6 +3038,11 @@ static noinline int do_init_module(struct module *mod) > if (mod->init != NULL) > ret = do_one_initcall(mod->init); > if (ret < 0) { > + if (ret == -EEXIST) { > + pr_warn("%s: init suspiciously returned -EEXIST: > Overriding with -EBUSY\n", > + mod->name); > + ret = -EBUSY; > + } > goto fail_free_freeinit; > } > if (ret > 0) { >
