From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Daniel Gomez <da.gomez@kernel.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Daniel Scally <djrscally@gmail.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Petr Pavlu <petr.pavlu@suse.com>,
Sami Tolvanen <samitolvanen@google.com>,
Aaron Tomlin <atomlin@atomlin.com>,
Lucas De Marchi <demarchi@kernel.org>,
linux-acpi@vger.kernel.org, linux-modules@vger.kernel.org,
linux-kernel@vger.kernel.org, Daniel Gomez <da.gomez@samsung.com>
Subject: Re: [PATCH] software node: replace -EEXIST with -EBUSY
Date: Mon, 22 Dec 2025 09:19:42 +0100 [thread overview]
Message-ID: <2025122203-purely-huntsman-7987@gregkh> (raw)
In-Reply-To: <20251220-dev-module-init-eexists-linux-acpi-v1-1-af59b1a0e217@samsung.com>
On Sat, Dec 20, 2025 at 04:55:00AM +0100, Daniel Gomez wrote:
> From: Daniel Gomez <da.gomez@samsung.com>
>
> The -EEXIST error code is reserved by the module loading infrastructure
> to indicate that a module is already loaded. When a module's init
> function returns -EEXIST, userspace tools like kmod interpret this as
> "module already loaded" and treat the operation as successful, returning
> 0 to the user even though the module initialization actually failed.
>
> This follows the precedent set by commit 54416fd76770 ("netfilter:
> conntrack: helper: Replace -EEXIST by -EBUSY") which fixed the same
> issue in nf_conntrack_helper_register().
>
> Affected modules:
> * meraki_mx100 pcengines_apuv2
>
> Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> ---
> The error code -EEXIST is reserved by the kernel module loader to
> indicate that a module with the same name is already loaded. When a
> module's init function returns -EEXIST, kmod interprets this as "module
> already loaded" and reports success instead of failure [1].
>
> The kernel module loader will include a safety net that provides -EEXIST
> to -EBUSY with a warning [2], and a documentation patch has been sent to
> prevent future occurrences [3].
>
> These affected code paths were identified using a static analysis tool
> [4] that traces -EEXIST returns to module_init(). The tool was developed
> with AI assistance and all findings were manually validated.
>
> Link: https://lore.kernel.org/all/aKEVQhJpRdiZSliu@orbyte.nwl.cc/ [1]
> Link: https://lore.kernel.org/all/20251013-module-warn-ret-v1-0-ab65b41af01f@intel.com/ [2]
> Link: https://lore.kernel.org/all/20251218-dev-module-init-eexists-modules-docs-v1-0-361569aa782a@samsung.com/ [3]
> Link: https://gitlab.com/-/snippets/4913469 [4]
> ---
> drivers/base/swnode.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
> index 16a8301c25d6..083593d99a18 100644
> --- a/drivers/base/swnode.c
> +++ b/drivers/base/swnode.c
> @@ -919,7 +919,7 @@ int software_node_register(const struct software_node *node)
> struct swnode *parent = software_node_to_swnode(node->parent);
>
> if (software_node_to_swnode(node))
> - return -EEXIST;
> + return -EBUSY;
While I understand the want for the module loader to be returning
-EBUSY, that doesn't really make sense down here in this layer of the
kernel.
So why doesn't the module loader turn -EEXIST return values into -EBUSY
if it wishes to pass that value on to userspace? Otherwise you are
going to be constantly playing "whack-a-mole" here and have really
set things up so that NO api can ever return EEXIST as an error value in
the future.
thanks,
greg k-h
next prev parent reply other threads:[~2025-12-22 8:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-20 3:55 [PATCH] software node: replace -EEXIST with -EBUSY Daniel Gomez
2025-12-21 21:59 ` Sakari Ailus
2025-12-22 4:40 ` Daniel Gomez
2025-12-22 8:19 ` Greg Kroah-Hartman [this message]
2025-12-22 8:48 ` Daniel Gomez
2025-12-22 11:56 ` Greg Kroah-Hartman
2026-01-06 14:24 ` Lucas De Marchi
2026-01-08 11:55 ` Daniel Gomez
2026-01-08 11:51 ` Daniel Gomez
2026-01-08 11:58 ` Greg Kroah-Hartman
2025-12-27 15:23 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2025122203-purely-huntsman-7987@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=atomlin@atomlin.com \
--cc=da.gomez@kernel.org \
--cc=da.gomez@samsung.com \
--cc=dakr@kernel.org \
--cc=demarchi@kernel.org \
--cc=djrscally@gmail.com \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=petr.pavlu@suse.com \
--cc=rafael@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=samitolvanen@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.