[PATCH] software node: replace -EEXIST with -EBUSY

[PATCH] software node: replace -EEXIST with -EBUSY

[Daniel Gomez]

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;
 
 	if (node->parent && !parent)
 		return -EINVAL;

---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20251219-dev-module-init-eexists-linux-acpi-110964d37acd

Best regards,
--  
Daniel Gomez <da.gomez@samsung.com>

Re: [PATCH] software node: replace -EEXIST with -EBUSY

[Sakari Ailus]

Hi Daniel,

Thanks for the patch.

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.

This might not be the only case where -EEXIST may be returned by loading a
module. The patch is fine IMO but I'd just change -EEXIST to -EBUSY in e.g.
do_init_module() to avoid this being an actual bug elsewhere.

I wonder what others think.

> 
> 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;
>  
>  	if (node->parent && !parent)
>  		return -EINVAL;
> 

-- 
Regards,

Sakari Ailus

Re: [PATCH] software node: replace -EEXIST with -EBUSY

[Daniel Gomez]

On 21/12/2025 22.59, Sakari Ailus wrote:
> Hi Daniel,
> 
> Thanks for the patch.
> 
> 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.
> 
> This might not be the only case where -EEXIST may be returned by loading a
> module.

That is correct. There are 40+ places detected and around 20+ more where
the error is returned but at some point ignored and not propagated back to
userspace. I have all the series ready for the first case, but I've only sent
the first 6.

> The patch is fine IMO but I'd just change -EEXIST to -EBUSY in e.g.
> do_init_module() to avoid this being an actual bug elsewhere.

We are planning to merge that too. Link [2] refers to Lucas's "[PATCH 0/2]
module: Tweak return and warning" series, which replaces -EEXIST with -EBUSY at
runtime and warns. However, we do not consider that to be the actual fix. I am
starting to send these fixes out to avoid "spamming" unnecessarily the kernel
log in cases we can already detect.

> 
> I wonder what others think.

Please, find the rest of the series sent:
https://lore.kernel.org/all/20251220-dev-module-init-eexists-linux-scsi-v1-0-5379db749d54@samsung.com
https://lore.kernel.org/all/20251219-dev-module-init-eexists-netfilter-v1-1-efd3f62412dc@samsung.com
https://lore.kernel.org/all/20251220-dev-module-init-eexists-bpf-v1-1-7f186663dbe7@samsung.com
https://lore.kernel.org/all/20251220-dev-module-init-eexists-keyring-v1-1-a2f23248c300@samsung.com
https://lore.kernel.org/all/20251220-dev-module-init-eexists-dm-devel-v1-1-90ed00444ea0@samsung.com

FYI, these docs go on top of Lucas' changes with the hope this is clear in the
docs.

https://lore.kernel.org/all/20251218-dev-module-init-eexists-modules-docs-v1-0-361569aa782a@samsung.com

> 
>>
>> 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]

Re: [PATCH] software node: replace -EEXIST with -EBUSY

[Greg Kroah-Hartman]

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

Re: [PATCH] software node: replace -EEXIST with -EBUSY

[Daniel Gomez]

On 22/12/2025 09.19, Greg Kroah-Hartman wrote:
> 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

Indeed, we are planning to do that as well with "[PATCH 0/2] module: Tweak
return and warning":

https://lore.kernel.org/all/20251013-module-warn-ret-v1-0-ab65b41af01f@intel.com/#t

However, we don't consider that as the right fix.

> 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.

100%.

For that reason, on top of the series from Lucas, we are documenting this to
make it clear:

https://lore.kernel.org/linux-modules/20251218-dev-module-init-eexists-modules-docs-v1-0-361569aa782a@samsung.com/T/#m2ed6fbffb3f78b9bff53840f6492a198c389cb50

And sending patches where we see modules need fixing. I have already sent 6 out
of 20-ish series (that include a total of 40+ fixes):

https://lore.kernel.org/all/20251220-dev-module-init-eexists-linux-scsi-v1-0-5379db749d54@samsung.com
https://lore.kernel.org/all/20251219-dev-module-init-eexists-netfilter-v1-1-efd3f62412dc@samsung.com
https://lore.kernel.org/all/20251220-dev-module-init-eexists-bpf-v1-1-7f186663dbe7@samsung.com
https://lore.kernel.org/all/20251220-dev-module-init-eexists-keyring-v1-1-a2f23248c300@samsung.com
https://lore.kernel.org/all/20251220-dev-module-init-eexists-dm-devel-v1-1-90ed00444ea0@samsung.com

Re: [PATCH] software node: replace -EEXIST with -EBUSY

[Greg Kroah-Hartman]

On Mon, Dec 22, 2025 at 09:48:54AM +0100, Daniel Gomez wrote:
> On 22/12/2025 09.19, Greg Kroah-Hartman wrote:
> > 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
> 
> Indeed, we are planning to do that as well with "[PATCH 0/2] module: Tweak
> return and warning":
> 
> https://lore.kernel.org/all/20251013-module-warn-ret-v1-0-ab65b41af01f@intel.com/#t
> 
> However, we don't consider that as the right fix.
> 
> > 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.
> 
> 100%.
> 
> For that reason, on top of the series from Lucas, we are documenting this to
> make it clear:
> 
> https://lore.kernel.org/linux-modules/20251218-dev-module-init-eexists-modules-docs-v1-0-361569aa782a@samsung.com/T/#m2ed6fbffb3f78b9bff53840f6492a198c389cb50

Wait, no, that's not what I mean at all :)

> And sending patches where we see modules need fixing. I have already sent 6 out
> of 20-ish series (that include a total of 40+ fixes):
> 
> https://lore.kernel.org/all/20251220-dev-module-init-eexists-linux-scsi-v1-0-5379db749d54@samsung.com
> https://lore.kernel.org/all/20251219-dev-module-init-eexists-netfilter-v1-1-efd3f62412dc@samsung.com
> https://lore.kernel.org/all/20251220-dev-module-init-eexists-bpf-v1-1-7f186663dbe7@samsung.com
> https://lore.kernel.org/all/20251220-dev-module-init-eexists-keyring-v1-1-a2f23248c300@samsung.com
> https://lore.kernel.org/all/20251220-dev-module-init-eexists-dm-devel-v1-1-90ed00444ea0@samsung.com

Please no, let us keep using -EEXIST in the kernel source, and if your
usage is going to map this to userspace somehow, do the translation
there, in the module code, as your original patch above said.

Otherwise, again, this is never going to work, let the subsystems use
this error code how ever they feel they need to.

thanks,

greg k-h

Re: [PATCH] software node: replace -EEXIST with -EBUSY

[Lucas De Marchi]

On Mon, Dec 22, 2025 at 12:56:38PM +0100, Greg Kroah-Hartman wrote:
>On Mon, Dec 22, 2025 at 09:48:54AM +0100, Daniel Gomez wrote:
>> On 22/12/2025 09.19, Greg Kroah-Hartman wrote:
>> > 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
>>
>> Indeed, we are planning to do that as well with "[PATCH 0/2] module: Tweak
>> return and warning":
>>
>> https://lore.kernel.org/all/20251013-module-warn-ret-v1-0-ab65b41af01f@intel.com/#t
>>
>> However, we don't consider that as the right fix.
>>
>> > 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.
>>
>> 100%.
>>
>> For that reason, on top of the series from Lucas, we are documenting this to
>> make it clear:
>>
>> https://lore.kernel.org/linux-modules/20251218-dev-module-init-eexists-modules-docs-v1-0-361569aa782a@samsung.com/T/#m2ed6fbffb3f78b9bff53840f6492a198c389cb50
>
>Wait, no, that's not what I mean at all :)
>
>> And sending patches where we see modules need fixing. I have already sent 6 out
>> of 20-ish series (that include a total of 40+ fixes):
>>
>> https://lore.kernel.org/all/20251220-dev-module-init-eexists-linux-scsi-v1-0-5379db749d54@samsung.com
>> https://lore.kernel.org/all/20251219-dev-module-init-eexists-netfilter-v1-1-efd3f62412dc@samsung.com
>> https://lore.kernel.org/all/20251220-dev-module-init-eexists-bpf-v1-1-7f186663dbe7@samsung.com
>> https://lore.kernel.org/all/20251220-dev-module-init-eexists-keyring-v1-1-a2f23248c300@samsung.com
>> https://lore.kernel.org/all/20251220-dev-module-init-eexists-dm-devel-v1-1-90ed00444ea0@samsung.com
>
>Please no, let us keep using -EEXIST in the kernel source, and if your
>usage is going to map this to userspace somehow, do the translation
>there, in the module code, as your original patch above said.
>
>Otherwise, again, this is never going to work, let the subsystems use
>this error code how ever they feel they need to.

Ok. When I added the warning I was more following what the other error
handling was doing for positive values. Happy to change that to simply
map the error code before returning from do_init_module().

Daniel, do you want me to resend that with the warning removed?

Lucas De Marchi

>
>thanks,
>
>greg k-h

Re: [PATCH] software node: replace -EEXIST with -EBUSY

[Daniel Gomez]

On 06/01/2026 15.24, Lucas De Marchi wrote:
> On Mon, Dec 22, 2025 at 12:56:38PM +0100, Greg Kroah-Hartman wrote:
>> On Mon, Dec 22, 2025 at 09:48:54AM +0100, Daniel Gomez wrote:
>>> On 22/12/2025 09.19, Greg Kroah-Hartman wrote:
>>> > 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
>>>
>>> Indeed, we are planning to do that as well with "[PATCH 0/2] module: Tweak
>>> return and warning":
>>>
>>> https://lore.kernel.org/all/20251013-module-warn-ret-v1-0-ab65b41af01f@intel.com/#t
>>>
>>> However, we don't consider that as the right fix.
>>>
>>> > 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.
>>>
>>> 100%.
>>>
>>> For that reason, on top of the series from Lucas, we are documenting this to
>>> make it clear:
>>>
>>> https://lore.kernel.org/linux-modules/20251218-dev-module-init-eexists-modules-docs-v1-0-361569aa782a@samsung.com/T/#m2ed6fbffb3f78b9bff53840f6492a198c389cb50
>>
>> Wait, no, that's not what I mean at all :)
>>
>>> And sending patches where we see modules need fixing. I have already sent 6 out
>>> of 20-ish series (that include a total of 40+ fixes):
>>>
>>> https://lore.kernel.org/all/20251220-dev-module-init-eexists-linux-scsi-v1-0-5379db749d54@samsung.com
>>> https://lore.kernel.org/all/20251219-dev-module-init-eexists-netfilter-v1-1-efd3f62412dc@samsung.com
>>> https://lore.kernel.org/all/20251220-dev-module-init-eexists-bpf-v1-1-7f186663dbe7@samsung.com
>>> https://lore.kernel.org/all/20251220-dev-module-init-eexists-keyring-v1-1-a2f23248c300@samsung.com
>>> https://lore.kernel.org/all/20251220-dev-module-init-eexists-dm-devel-v1-1-90ed00444ea0@samsung.com
>>
>> Please no, let us keep using -EEXIST in the kernel source, and if your
>> usage is going to map this to userspace somehow, do the translation
>> there, in the module code, as your original patch above said.
>>
>> Otherwise, again, this is never going to work, let the subsystems use
>> this error code how ever they feel they need to.
> 
> Ok. When I added the warning I was more following what the other error
> handling was doing for positive values. Happy to change that to simply
> map the error code before returning from do_init_module().
> 
> Daniel, do you want me to resend that with the warning removed?

Yes please, I think we should do that and explain the agreement in this thread
in the commit message so others can understand the why.

Re: [PATCH] software node: replace -EEXIST with -EBUSY

[Daniel Gomez]

On 22/12/2025 12.56, Greg Kroah-Hartman wrote:
> On Mon, Dec 22, 2025 at 09:48:54AM +0100, Daniel Gomez wrote:
>> On 22/12/2025 09.19, Greg Kroah-Hartman wrote:
>>> 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
>>
>> Indeed, we are planning to do that as well with "[PATCH 0/2] module: Tweak
>> return and warning":
>>
>> https://lore.kernel.org/all/20251013-module-warn-ret-v1-0-ab65b41af01f@intel.com/#t
>>
>> However, we don't consider that as the right fix.
>>
>>> 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.
>>
>> 100%.
>>
>> For that reason, on top of the series from Lucas, we are documenting this to
>> make it clear:
>>
>> https://lore.kernel.org/linux-modules/20251218-dev-module-init-eexists-modules-docs-v1-0-361569aa782a@samsung.com/T/#m2ed6fbffb3f78b9bff53840f6492a198c389cb50
> 
> Wait, no, that's not what I mean at all :)
> 
>> And sending patches where we see modules need fixing. I have already sent 6 out
>> of 20-ish series (that include a total of 40+ fixes):
>>
>> https://lore.kernel.org/all/20251220-dev-module-init-eexists-linux-scsi-v1-0-5379db749d54@samsung.com
>> https://lore.kernel.org/all/20251219-dev-module-init-eexists-netfilter-v1-1-efd3f62412dc@samsung.com
>> https://lore.kernel.org/all/20251220-dev-module-init-eexists-bpf-v1-1-7f186663dbe7@samsung.com
>> https://lore.kernel.org/all/20251220-dev-module-init-eexists-keyring-v1-1-a2f23248c300@samsung.com
>> https://lore.kernel.org/all/20251220-dev-module-init-eexists-dm-devel-v1-1-90ed00444ea0@samsung.com
> 
> Please no, let us keep using -EEXIST in the kernel source, and if your

This is not just random places in the kernel. It's only errors in the module
initialization path.

> usage is going to map this to userspace somehow, do the translation
> there, in the module code, as your original patch above said.
> > Otherwise, again, this is never going to work, let the subsystems use
> this error code how ever they feel they need to.

I considered module_init() (somehow) to be part of the module code, and
replacing the error at the module loading layer felt like a hack to me. My
concern is that a module_init() user expecting -EEXIST to propagate to userspace
won't get it as it will be silently replaced. But without a concrete use case
where that matters, I'll go with the consensus. Note that I'm hinting at we
should remove the warning from Lucas' original patch [1] before merging it.

Link: https://lore.kernel.org/all/20251013-module-warn-ret-v1-1-ab65b41af01f@intel.com/ [1]

Re: [PATCH] software node: replace -EEXIST with -EBUSY

[Greg Kroah-Hartman]

On Thu, Jan 08, 2026 at 12:51:46PM +0100, Daniel Gomez wrote:
> 
> 
> On 22/12/2025 12.56, Greg Kroah-Hartman wrote:
> > On Mon, Dec 22, 2025 at 09:48:54AM +0100, Daniel Gomez wrote:
> >> On 22/12/2025 09.19, Greg Kroah-Hartman wrote:
> >>> 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
> >>
> >> Indeed, we are planning to do that as well with "[PATCH 0/2] module: Tweak
> >> return and warning":
> >>
> >> https://lore.kernel.org/all/20251013-module-warn-ret-v1-0-ab65b41af01f@intel.com/#t
> >>
> >> However, we don't consider that as the right fix.
> >>
> >>> 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.
> >>
> >> 100%.
> >>
> >> For that reason, on top of the series from Lucas, we are documenting this to
> >> make it clear:
> >>
> >> https://lore.kernel.org/linux-modules/20251218-dev-module-init-eexists-modules-docs-v1-0-361569aa782a@samsung.com/T/#m2ed6fbffb3f78b9bff53840f6492a198c389cb50
> > 
> > Wait, no, that's not what I mean at all :)
> > 
> >> And sending patches where we see modules need fixing. I have already sent 6 out
> >> of 20-ish series (that include a total of 40+ fixes):
> >>
> >> https://lore.kernel.org/all/20251220-dev-module-init-eexists-linux-scsi-v1-0-5379db749d54@samsung.com
> >> https://lore.kernel.org/all/20251219-dev-module-init-eexists-netfilter-v1-1-efd3f62412dc@samsung.com
> >> https://lore.kernel.org/all/20251220-dev-module-init-eexists-bpf-v1-1-7f186663dbe7@samsung.com
> >> https://lore.kernel.org/all/20251220-dev-module-init-eexists-keyring-v1-1-a2f23248c300@samsung.com
> >> https://lore.kernel.org/all/20251220-dev-module-init-eexists-dm-devel-v1-1-90ed00444ea0@samsung.com
> > 
> > Please no, let us keep using -EEXIST in the kernel source, and if your
> 
> This is not just random places in the kernel. It's only errors in the module
> initialization path.

The "module initialization path" is deep.  really really deep.  Look at
the "probe" path for many drivers, that can be quite intensive and deep,
so attempting to audit all EEXIST errors for all of those paths is going
to be rough, if impossible.

thanks,

greg k-h

Re: [PATCH] software node: replace -EEXIST with -EBUSY

[Andy Shevchenko]

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

As I read the description the problem is in the kmod/do_module_init(). If you
need a clear way to distinguish that, use some unique error code in the kernel
module loader. I fully agree with Greg that this is a slippery slope which
leads to -EEXIST to be forbidden in the drivers which is no go.

NAK.

-- 
With Best Regards,
Andy Shevchenko