* Re: [PATCH] module: Remove unused __INIT*_OR_MODULE macros
From: Sami Tolvanen @ 2025-12-22 20:24 UTC (permalink / raw)
To: Luis Chamberlain, Daniel Gomez, Petr Pavlu
Cc: Sami Tolvanen, linux-modules, linux-kernel
In-Reply-To: <20250819121423.460156-1-petr.pavlu@suse.com>
On Tue, 19 Aug 2025 14:13:37 +0200, Petr Pavlu wrote:
> Remove the __INIT_OR_MODULE, __INITDATA_OR_MODULE and
> __INITRODATA_OR_MODULE macros. These were introduced in commit 8b5a10fc6fd0
> ("x86: properly annotate alternatives.c"). Only __INITRODATA_OR_MODULE was
> ever used, in arch/x86/kernel/alternative.c. In 2011, commit dc326fca2b64
> ("x86, cpu: Clean up and unify the NOP selection infrastructure") removed
> this usage.
>
> [...]
Applied to modules-next, thanks!
[1/1] module: Remove unused __INIT*_OR_MODULE macros
commit: f13bff1b6d55de341f37a24781df5a1253377db3
Best regards,
Sami
^ permalink raw reply
* Re: [PATCH 0/2] module: Remove SHA-1 support for module signing
From: Sami Tolvanen @ 2025-12-22 20:24 UTC (permalink / raw)
To: David Howells, David Woodhouse, Luis Chamberlain, Daniel Gomez,
Aaron Tomlin, Petr Pavlu
Cc: Sami Tolvanen, keyrings, linux-modules, linux-kernel
In-Reply-To: <20251111154923.978181-1-petr.pavlu@suse.com>
On Tue, 11 Nov 2025 16:48:30 +0100, Petr Pavlu wrote:
> SHA-1 is considered deprecated and insecure due to vulnerabilities that can
> lead to hash collisions. Most distributions have already been using SHA-2
> for module signing because of this. The default was also changed last year
> from SHA-1 to SHA-512 in f3b93547b91a ("module: sign with sha512 instead of
> sha1 by default"). This was not reported to cause any issues. Therefore, it
> now seems to be a good time to remove SHA-1 support for module signing.
>
> [...]
Applied to modules-next, thanks!
[1/2] module: Remove SHA-1 support for module signing
commit: 148519a06304af4e6fbb82f20e1a4480e2c1b126
[2/2] sign-file: Use only the OpenSSL CMS API for signing
commit: d7afd65b4acc775df872af30948dd7c196587169
Best regards,
Sami
^ permalink raw reply
* Re: [PATCH v3] module: replace use of system_wq with system_dfl_wq
From: Sami Tolvanen @ 2025-12-22 20:24 UTC (permalink / raw)
To: linux-kernel, linux-modules, Marco Crivellari
Cc: Sami Tolvanen, Tejun Heo, Lai Jiangshan, Frederic Weisbecker,
Sebastian Andrzej Siewior, Michal Hocko, Luis Chamberlain,
Petr Pavlu
In-Reply-To: <20251111095049.67658-1-marco.crivellari@suse.com>
On Tue, 11 Nov 2025 10:50:49 +0100, Marco Crivellari wrote:
> Currently if a user enqueues a work item using schedule_delayed_work() the
> used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
> WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
> schedule_work() that is using system_wq and queue_work(), that makes use
> again of WORK_CPU_UNBOUND.
>
> This lack of consistency cannot be addressed without refactoring the API.
>
> [...]
Applied to modules-next, thanks!
[1/1] module: replace use of system_wq with system_dfl_wq
commit: 581ac2d4a58b81669cc6abf645a558bce5cf14ab
Best regards,
Sami
^ permalink raw reply
* Re: [PATCH] module/decompress: Avoid open-coded kvrealloc()
From: Sami Tolvanen @ 2025-12-22 20:24 UTC (permalink / raw)
To: Petr Pavlu, Kees Cook
Cc: Sami Tolvanen, Luis Chamberlain, Daniel Gomez, linux-modules,
Daniel Gomez, linux-kernel, linux-hardening
In-Reply-To: <20251119225439.work.741-kees@kernel.org>
On Wed, 19 Nov 2025 14:54:43 -0800, Kees Cook wrote:
> Replace open-coded allocate/copy with kvrealloc().
>
>
Applied to modules-next, thanks!
[1/1] module/decompress: Avoid open-coded kvrealloc()
commit: 68e85558587e6bbb5c3ea3c8b4c71ab852e4b53e
Best regards,
Sami
^ permalink raw reply
* Re: [PATCH v2] module: Only declare set_module_sig_enforced when CONFIG_MODULE_SIG=y
From: Sami Tolvanen @ 2025-12-22 20:24 UTC (permalink / raw)
To: linux-modules, Coiby Xu
Cc: Sami Tolvanen, linux-integrity, kernel test robot, Aaron Tomlin,
Daniel Gomez, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
linux-kernel
In-Reply-To: <20251201030606.2295399-1-coxu@redhat.com>
On Mon, 01 Dec 2025 11:06:05 +0800, Coiby Xu wrote:
> Currently if set_module_sig_enforced is called with CONFIG_MODULE_SIG=n
> e.g. [1], it can lead to a linking error,
>
> ld: security/integrity/ima/ima_appraise.o: in function `ima_appraise_measurement':
> security/integrity/ima/ima_appraise.c:587:(.text+0xbbb): undefined reference to `set_module_sig_enforced'
>
> This happens because the actual implementation of
> set_module_sig_enforced comes from CONFIG_MODULE_SIG but both the
> function declaration and the empty stub definition are tied to
> CONFIG_MODULES.
>
> [...]
Applied to modules-next, thanks!
[1/1] module: Only declare set_module_sig_enforced when CONFIG_MODULE_SIG=y
commit: 1ae719a43b0336678172b3eb55c5187816f9a130
Best regards,
Sami
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Update module subsystem maintainers and repository
From: Sami Tolvanen @ 2025-12-22 20:23 UTC (permalink / raw)
To: Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen
Cc: Aaron Tomlin, linux-modules, linux-kernel
In-Reply-To: <20251215215545.1332626-2-samitolvanen@google.com>
On Mon, 15 Dec 2025 21:55:46 +0000, Sami Tolvanen wrote:
> Add myself as a maintainer for module support as I'll be handling pull
> requests for the next six months according to the previously announced
> rotation [1][2]. Also, update the git repository link to point to the
> modules tree, which is already used by linux-next.
>
>
Applied to modules-next, thanks!
[1/1] MAINTAINERS: Update module subsystem maintainers and repository
commit: d8275cdaf20e5262141dcd12b214cf035d07ed9d
Best regards,
Sami
^ permalink raw reply
* Re: [PATCH] software node: replace -EEXIST with -EBUSY
From: Greg Kroah-Hartman @ 2025-12-22 11:56 UTC (permalink / raw)
To: Daniel Gomez
Cc: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Rafael J. Wysocki, Danilo Krummrich, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Aaron Tomlin, Lucas De Marchi, linux-acpi,
linux-modules, linux-kernel, Daniel Gomez
In-Reply-To: <7ff92075-df6a-45d8-9014-647ae45797ff@kernel.org>
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
^ permalink raw reply
* Re: [PATCH] software node: replace -EEXIST with -EBUSY
From: Daniel Gomez @ 2025-12-22 8:48 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Rafael J. Wysocki, Danilo Krummrich, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Aaron Tomlin, Lucas De Marchi, linux-acpi,
linux-modules, linux-kernel, Daniel Gomez
In-Reply-To: <2025122203-purely-huntsman-7987@gregkh>
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
^ permalink raw reply
* Re: [PATCH] software node: replace -EEXIST with -EBUSY
From: Greg Kroah-Hartman @ 2025-12-22 8:19 UTC (permalink / raw)
To: Daniel Gomez
Cc: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Rafael J. Wysocki, Danilo Krummrich, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Aaron Tomlin, Lucas De Marchi, linux-acpi,
linux-modules, linux-kernel, Daniel Gomez
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
^ permalink raw reply
* Re: [PATCH] software node: replace -EEXIST with -EBUSY
From: Daniel Gomez @ 2025-12-22 4:40 UTC (permalink / raw)
To: Sakari Ailus
Cc: Andy Shevchenko, Daniel Scally, Heikki Krogerus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Aaron Tomlin,
Lucas De Marchi, linux-acpi, linux-modules, linux-kernel,
Daniel Gomez
In-Reply-To: <aUht13bTn-lEnNM-@kekkonen.localdomain>
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]
^ permalink raw reply
* Re: [PATCH] software node: replace -EEXIST with -EBUSY
From: Sakari Ailus @ 2025-12-21 21:59 UTC (permalink / raw)
To: Daniel Gomez
Cc: Andy Shevchenko, Daniel Scally, Heikki Krogerus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Aaron Tomlin,
Lucas De Marchi, linux-acpi, linux-modules, linux-kernel,
Daniel Gomez
In-Reply-To: <20251220-dev-module-init-eexists-linux-acpi-v1-1-af59b1a0e217@samsung.com>
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
^ permalink raw reply
* /proc/modules address+size bounds are inconsistent
From: Tatsuyuki Ishi @ 2025-12-21 12:52 UTC (permalink / raw)
To: mcgrof, petr.pavlu, da.gomez; +Cc: song, linux-modules
Hi,
I noticed that /proc/modules reports inconsistent address and size
values for modules. In m_show():
size = module_total_size(mod); // .text + .rodata +
.data + ...
value = mod->mem[MOD_TEXT].base; // only text base
Looking at kallsyms, .data symbols can come before .text symbols, so
[addr, addr+size) is useless as a bound and can be overlapping.
I have a userspace frontend for perf [1] and the code currently
expects non-overlapping regions. I can add a workaround to truncate
any overlapping regions from /proc/modules. But is it possible to
"fix" the kernel-side semantics here?
[1]: https://github.com/mstange/samply/pull/736
^ permalink raw reply
* Re: [PATCH 0/2] scsi: target+fcoe: replace -EEXIST with -EBUSY in module_init() paths
From: Daniel Gomez @ 2025-12-21 10:00 UTC (permalink / raw)
To: James Bottomley, Martin K. Petersen, Hannes Reinecke
Cc: Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Aaron Tomlin,
Lucas De Marchi, linux-scsi, target-devel, linux-modules,
linux-kernel, Daniel Gomez
In-Reply-To: <6be5a2cfdeb6af71f6bd676e71418393d78e93e0.camel@HansenPartnership.com>
On 21/12/2025 05.02, James Bottomley wrote:
> On Sun, 2025-12-21 at 04:30 +0100, Daniel Gomez wrote:
>> On 20/12/2025 05.27, James Bottomley wrote:
>>> On Sat, 2025-12-20 at 04:37 +0100, Daniel Gomez wrote:
> None of that answers the why question: Given that EEXIST is used all
> over the kernel, for what appear to be fairly legitimate cases, why
> would we suddenly want it to become only for modules? I get that we
> can, as you propose patches above, but why should we bother? It seems
> to be a useful error code outside the module use case, so why the need
> to restrict it to being only for modules?
Because both the module loader and module_init() return through the same
(f)init_module() syscall path, we need to ensure consistency in what we report
back to userspace. The init_module(2) man page documents EEXIST as "a module
with this name is already loaded." When module_init() returns EEXIST for
a different reason, userspace tools following the documented behavior will
misinterpret it. We can't use the same error code for different meanings and
expect the caller to differentiate.
^ permalink raw reply
* Re: [PATCH 0/2] scsi: target+fcoe: replace -EEXIST with -EBUSY in module_init() paths
From: James Bottomley @ 2025-12-21 4:02 UTC (permalink / raw)
To: Daniel Gomez, Martin K. Petersen, Hannes Reinecke
Cc: Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Aaron Tomlin,
Lucas De Marchi, linux-scsi, target-devel, linux-modules,
linux-kernel, Daniel Gomez
In-Reply-To: <799f5069-36a1-4be7-8ee3-acb3a6cd44a2@kernel.org>
On Sun, 2025-12-21 at 04:30 +0100, Daniel Gomez wrote:
> On 20/12/2025 05.27, James Bottomley wrote:
> > On Sat, 2025-12-20 at 04:37 +0100, Daniel Gomez wrote:
> > > 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].
> >
> > That reference doesn't sufficiently explain why this error code
> > should be unique to modules.
>
> It's unique only to the module initialization. You can find how it's
> used in the kernel module code at module_patient_check_exists() in
> kernel/module/main.c [1].
>
> In addition, init_module(2) man pages indicates this:
>
> man 2 init_module | grep EEXIST
> EEXIST A module with this name is already loaded.
>
> So, a module that is already loaded will be detected by the kernel
> module loader and the EEXIST error will be returned. This will be
> detected by kmod as success [2]. I think this functionality was added
> very early on in kmod by commit 5f35147 "libkmod-module: probe: add
> flag to stop loading on already loaded" [3]. Prior to that, module-
> init-tools had the same behavior [4]. Even in
> modutils [5], we had back then in insmod/insmod.c:2088:
>
> case EEXIST:
> if (dolock) {
> /*
> * Assume that we were just invoked
> * simultaneous with another insmod
> * and return success.
> */
> exit_status = 0;
> goto out;
> }
> error("a module named %s already exists",
> m_name);
> goto out;
>
> Link:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/module/main.c?h=v6.19-rc1#n3206
> [1]
> Link:
> https://github.com/kmod-project/kmod/blob/v34.2/libkmod/libkmod-module.c#L1088
> [2]
> Link:
> https://github.com/kmod-project/kmod/commit/5f3514731ef82084c1a24b15445e0f1352681a19
> [3]
> Link:
> https://git.kernel.org/pub/scm/utils/kernel/module-init-tools/module-init-tools.git/tree/modprobe.c#n1797
> [4]
> Link:
> https://cdn.kernel.org/pub/linux/utils/kernel/modutils/v2.4/modutils-2.4.27.tar.gz
> [5]
>
> > EEXIST is used all over the kernel to indicate
> > that something being attempted has already happened or does already
> > exist and that seems perfectly logical .... please explain why
> > you're
>
> That is correct but not all are conflicts within the
> module_init()/init_module(2) path. I have detected 40+ cases where
> this error is returned and another 20+ where error is returned but in
> upper layers of the module itself, not propagated back to userspace.
> So far, I've only sent just a few + docs:
>
> https://lore.kernel.org/all/20251220-dev-module-init-eexists-dm-devel-v1-1-90ed00444ea0@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-linux-acpi-v1-1-af59b1a0e217@samsung.com
> https://lore.kernel.org/all/20251218-dev-module-init-eexists-modules-docs-v1-0-361569aa782a@samsung.com
None of that answers the why question: Given that EEXIST is used all
over the kernel, for what appear to be fairly legitimate cases, why
would we suddenly want it to become only for modules? I get that we
can, as you propose patches above, but why should we bother? It seems
to be a useful error code outside the module use case, so why the need
to restrict it to being only for modules?
Regards,
James
^ permalink raw reply
* Re: [PATCH 0/2] scsi: target+fcoe: replace -EEXIST with -EBUSY in module_init() paths
From: Daniel Gomez @ 2025-12-21 3:30 UTC (permalink / raw)
To: James Bottomley, Martin K. Petersen, Hannes Reinecke
Cc: Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Aaron Tomlin,
Lucas De Marchi, linux-scsi, target-devel, linux-modules,
linux-kernel, Daniel Gomez
In-Reply-To: <b1e372cacf08a758e06ce7504c6cfaf7778bc6f3.camel@HansenPartnership.com>
On 20/12/2025 05.27, James Bottomley wrote:
> On Sat, 2025-12-20 at 04:37 +0100, Daniel Gomez wrote:
>> 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].
>
> That reference doesn't sufficiently explain why this error code should
> be unique to modules.
It's unique only to the module initialization. You can find how it's used in the
kernel module code at module_patient_check_exists() in kernel/module/main.c [1].
In addition, init_module(2) man pages indicates this:
man 2 init_module | grep EEXIST
EEXIST A module with this name is already loaded.
So, a module that is already loaded will be detected by the kernel module loader
and the EEXIST error will be returned. This will be detected by kmod as success
[2]. I think this functionality was added very early on in kmod by commit
5f35147 "libkmod-module: probe: add flag to stop loading on already loaded" [3].
Prior to that, module-init-tools had the same behavior [4]. Even in modutils
[5], we had back then in insmod/insmod.c:2088:
case EEXIST:
if (dolock) {
/*
* Assume that we were just invoked
* simultaneous with another insmod
* and return success.
*/
exit_status = 0;
goto out;
}
error("a module named %s already exists", m_name);
goto out;
Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/module/main.c?h=v6.19-rc1#n3206 [1]
Link: https://github.com/kmod-project/kmod/blob/v34.2/libkmod/libkmod-module.c#L1088 [2]
Link: https://github.com/kmod-project/kmod/commit/5f3514731ef82084c1a24b15445e0f1352681a19 [3]
Link: https://git.kernel.org/pub/scm/utils/kernel/module-init-tools/module-init-tools.git/tree/modprobe.c#n1797 [4]
Link: https://cdn.kernel.org/pub/linux/utils/kernel/modutils/v2.4/modutils-2.4.27.tar.gz [5]
> EEXIST is used all over the kernel to indicate
> that something being attempted has already happened or does already
> exist and that seems perfectly logical .... please explain why you're
That is correct but not all are conflicts within the
module_init()/init_module(2) path. I have detected 40+ cases where this error
is returned and another 20+ where error is returned but in upper layers of
the module itself, not propagated back to userspace. So far, I've only sent just
a few + docs:
https://lore.kernel.org/all/20251220-dev-module-init-eexists-dm-devel-v1-1-90ed00444ea0@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-linux-acpi-v1-1-af59b1a0e217@samsung.com
https://lore.kernel.org/all/20251218-dev-module-init-eexists-modules-docs-v1-0-361569aa782a@samsung.com
> trying to push it back to being a single use case for modules alone.
>
> Regards,
>
> James
>
>
>
^ permalink raw reply
* Re: [PATCH] netfilter: replace -EEXIST with -EBUSY
From: Florian Westphal @ 2025-12-20 19:16 UTC (permalink / raw)
To: Daniel Gomez
Cc: Pablo Neira Ayuso, Jozsef Kadlecsik, Phil Sutter,
Nikolay Aleksandrov, Ido Schimmel, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Luis Chamberlain,
Petr Pavlu, Sami Tolvanen, Aaron Tomlin, Lucas De Marchi,
netfilter-devel, coreteam, bridge, netdev, linux-modules,
linux-kernel, Daniel Gomez
In-Reply-To: <fdb9f97d-7813-48a0-9fdf-ddc039d853eb@kernel.org>
Daniel Gomez <da.gomez@kernel.org> wrote:
> something like:
>
> Replace -EEXIST with -EBUSY to ensure correct error reporting in the module
> initialization path.
Makes sense, I will mangle it locally when I apply this. Thanks!
^ permalink raw reply
* Re: [PATCH] bpf: crypto: replace -EEXIST with -EBUSY
From: Vadim Fedorenko @ 2025-12-20 18:55 UTC (permalink / raw)
To: Daniel Gomez, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa
Cc: Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Aaron Tomlin,
Lucas De Marchi, bpf, linux-modules, linux-kernel, Daniel Gomez
In-Reply-To: <20251220-dev-module-init-eexists-bpf-v1-1-7f186663dbe7@samsung.com>
On 20/12/2025 03:48, 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().
>
> This affects bpf_crypto_skcipher module. While the configuration
> required to build it as a module is unlikely in practice, it is
> technically possible, so fix it for correctness.
>
> 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]
Even though I'm not quite sure that we should care once the core
module loader can adjust the error, the change looks ok to me:
Acked-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
^ permalink raw reply
* Re: [PATCH 0/2] scsi: target+fcoe: replace -EEXIST with -EBUSY in module_init() paths
From: James Bottomley @ 2025-12-20 4:27 UTC (permalink / raw)
To: Daniel Gomez, Martin K. Petersen, Hannes Reinecke
Cc: Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Aaron Tomlin,
Lucas De Marchi, linux-scsi, target-devel, linux-modules,
linux-kernel, Daniel Gomez
In-Reply-To: <20251220-dev-module-init-eexists-linux-scsi-v1-0-5379db749d54@samsung.com>
On Sat, 2025-12-20 at 04:37 +0100, Daniel Gomez wrote:
> 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].
That reference doesn't sufficiently explain why this error code should
be unique to modules. EEXIST is used all over the kernel to indicate
that something being attempted has already happened or does already
exist and that seems perfectly logical .... please explain why you're
trying to push it back to being a single use case for modules alone.
Regards,
James
^ permalink raw reply
* [PATCH] software node: replace -EEXIST with -EBUSY
From: Daniel Gomez @ 2025-12-20 3:55 UTC (permalink / raw)
To: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich
Cc: Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Lucas De Marchi, linux-acpi, linux-modules,
linux-kernel, 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>
^ permalink raw reply related
* [PATCH] KEYS: replace -EEXIST with -EBUSY
From: Daniel Gomez @ 2025-12-20 3:50 UTC (permalink / raw)
To: David Howells, Lukas Wunner, Ignat Korchagin, Herbert Xu,
David S. Miller, Jarkko Sakkinen, Paul Moore, James Morris,
Serge E. Hallyn
Cc: Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Lucas De Marchi, keyrings, linux-crypto,
linux-modules, linux-kernel, linux-security-module, 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:
* pkcs8_key_parser x509_key_parser asymmetric_keys dns_resolver
* nvme_keyring pkcs7_test_key rxrpc turris_signing_key
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]
---
crypto/asymmetric_keys/asymmetric_type.c | 2 +-
security/keys/key.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/crypto/asymmetric_keys/asymmetric_type.c b/crypto/asymmetric_keys/asymmetric_type.c
index 348966ea2175..2c6f3a725102 100644
--- a/crypto/asymmetric_keys/asymmetric_type.c
+++ b/crypto/asymmetric_keys/asymmetric_type.c
@@ -634,7 +634,7 @@ int register_asymmetric_key_parser(struct asymmetric_key_parser *parser)
if (strcmp(cursor->name, parser->name) == 0) {
pr_err("Asymmetric key parser '%s' already registered\n",
parser->name);
- ret = -EEXIST;
+ ret = -EBUSY;
goto out;
}
}
diff --git a/security/keys/key.c b/security/keys/key.c
index 3bbdde778631..ed597660f72e 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -1219,7 +1219,7 @@ EXPORT_SYMBOL(generic_key_instantiate);
*
* Register a new key type.
*
- * Returns 0 on success or -EEXIST if a type of this name already exists.
+ * Returns 0 on success or -EBUSY if a type of this name already exists.
*/
int register_key_type(struct key_type *ktype)
{
@@ -1228,7 +1228,7 @@ int register_key_type(struct key_type *ktype)
memset(&ktype->lock_class, 0, sizeof(ktype->lock_class));
- ret = -EEXIST;
+ ret = -EBUSY;
down_write(&key_types_sem);
/* disallow key types with the same name */
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20251218-dev-module-init-eexists-keyring-5b008d7efb40
Best regards,
--
Daniel Gomez <da.gomez@samsung.com>
^ permalink raw reply related
* [PATCH] dm: replace -EEXIST with -EBUSY
From: Daniel Gomez @ 2025-12-20 3:49 UTC (permalink / raw)
To: Alasdair Kergon, Mike Snitzer, Mikulas Patocka,
Benjamin Marzinski
Cc: Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Lucas De Marchi, dm-devel, linux-modules,
linux-kernel, 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:
* dm_cache dm_clone dm_integrity dm_mirror dm_multipath dm_pcache
* dm_vdo dm-ps-round-robin dm_historical_service_time dm_io_affinity
* dm_queue_length dm_service_time dm_snapshot
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/md/dm-exception-store.c | 2 +-
drivers/md/dm-log.c | 2 +-
drivers/md/dm-path-selector.c | 2 +-
drivers/md/dm-target.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/md/dm-exception-store.c b/drivers/md/dm-exception-store.c
index c3799757bf4a..88f119a0a2ae 100644
--- a/drivers/md/dm-exception-store.c
+++ b/drivers/md/dm-exception-store.c
@@ -116,7 +116,7 @@ int dm_exception_store_type_register(struct dm_exception_store_type *type)
if (!__find_exception_store_type(type->name))
list_add(&type->list, &_exception_store_types);
else
- r = -EEXIST;
+ r = -EBUSY;
spin_unlock(&_lock);
return r;
diff --git a/drivers/md/dm-log.c b/drivers/md/dm-log.c
index 9d85d045f9d9..bced5a783ee3 100644
--- a/drivers/md/dm-log.c
+++ b/drivers/md/dm-log.c
@@ -121,7 +121,7 @@ int dm_dirty_log_type_register(struct dm_dirty_log_type *type)
if (!__find_dirty_log_type(type->name))
list_add(&type->list, &_log_types);
else
- r = -EEXIST;
+ r = -EBUSY;
spin_unlock(&_lock);
return r;
diff --git a/drivers/md/dm-path-selector.c b/drivers/md/dm-path-selector.c
index d0b883fabfeb..2b0ac200f1c0 100644
--- a/drivers/md/dm-path-selector.c
+++ b/drivers/md/dm-path-selector.c
@@ -107,7 +107,7 @@ int dm_register_path_selector(struct path_selector_type *pst)
if (__find_path_selector_type(pst->name)) {
kfree(psi);
- r = -EEXIST;
+ r = -EBUSY;
} else
list_add(&psi->list, &_path_selectors);
diff --git a/drivers/md/dm-target.c b/drivers/md/dm-target.c
index 8fede41adec0..1fd41289de36 100644
--- a/drivers/md/dm-target.c
+++ b/drivers/md/dm-target.c
@@ -88,7 +88,7 @@ int dm_register_target(struct target_type *tt)
if (__find_target_type(tt->name)) {
DMERR("%s: '%s' target already registered",
__func__, tt->name);
- rv = -EEXIST;
+ rv = -EBUSY;
} else {
list_add(&tt->list, &_targets);
}
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20251218-dev-module-init-eexists-dm-devel-2d656f9f2365
Best regards,
--
Daniel Gomez <da.gomez@samsung.com>
^ permalink raw reply related
* [PATCH] bpf: crypto: replace -EEXIST with -EBUSY
From: Daniel Gomez @ 2025-12-20 3:48 UTC (permalink / raw)
To: Vadim Fedorenko, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa
Cc: Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Lucas De Marchi, bpf, linux-modules, linux-kernel,
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().
This affects bpf_crypto_skcipher module. While the configuration
required to build it as a module is unlikely in practice, it is
technically possible, so fix it for correctness.
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]
---
kernel/bpf/crypto.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/crypto.c b/kernel/bpf/crypto.c
index 83c4d9943084..1ab79a6dec84 100644
--- a/kernel/bpf/crypto.c
+++ b/kernel/bpf/crypto.c
@@ -60,7 +60,7 @@ struct bpf_crypto_ctx {
int bpf_crypto_register_type(const struct bpf_crypto_type *type)
{
struct bpf_crypto_type_list *node;
- int err = -EEXIST;
+ int err = -EBUSY;
down_write(&bpf_crypto_types_sem);
list_for_each_entry(node, &bpf_crypto_types, list) {
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20251219-dev-module-init-eexists-bpf-da2aa3577437
Best regards,
--
Daniel Gomez <da.gomez@samsung.com>
^ permalink raw reply related
* [PATCH] driver core: attribute_container: change return type to void
From: Daniel Gomez @ 2025-12-20 3:45 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
James E.J. Bottomley, Martin K. Petersen
Cc: Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Lucas De Marchi, linux-scsi, linux-modules,
linux-kernel, Daniel Gomez
From: Daniel Gomez <da.gomez@samsung.com>
attribute_container_register() has always returned 0 since its
introduction in commit 06ff5a987e ("Add attribute container to generic
device model") in the historical Linux tree [1]. Convert the return type
to void and update all callers.
This removes dead code where callers checked for errors that could never
occur.
Link: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git [1]
Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
Cleanup. Found while reviewing module_init() return values for the
-EEXIST issue [1] on the scsi spi transport module.
Link: https://lore.kernel.org/linux-modules/20251220-dev-module-init-eexists-linux-scsi-v1-0-5379db749d54@samsung.com/T/#t [1]
---
drivers/base/attribute_container.c | 4 +---
drivers/base/transport_class.c | 8 ++------
drivers/scsi/scsi_transport_spi.c | 2 +-
include/linux/attribute_container.h | 2 +-
include/linux/transport_class.h | 6 +++---
5 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/drivers/base/attribute_container.c b/drivers/base/attribute_container.c
index b6f941a6ab69..72adbacc6554 100644
--- a/drivers/base/attribute_container.c
+++ b/drivers/base/attribute_container.c
@@ -69,7 +69,7 @@ static DEFINE_MUTEX(attribute_container_mutex);
* @cont: The container to register. This must be allocated by the
* callee and should also be zeroed by it.
*/
-int
+void
attribute_container_register(struct attribute_container *cont)
{
INIT_LIST_HEAD(&cont->node);
@@ -79,8 +79,6 @@ attribute_container_register(struct attribute_container *cont)
mutex_lock(&attribute_container_mutex);
list_add_tail(&cont->node, &attribute_container_list);
mutex_unlock(&attribute_container_mutex);
-
- return 0;
}
EXPORT_SYMBOL_GPL(attribute_container_register);
diff --git a/drivers/base/transport_class.c b/drivers/base/transport_class.c
index 09ee2a1e35bb..4b1e8820e764 100644
--- a/drivers/base/transport_class.c
+++ b/drivers/base/transport_class.c
@@ -88,17 +88,13 @@ static int anon_transport_dummy_function(struct transport_container *tc,
* events. Use prezero and then use DECLARE_ANON_TRANSPORT_CLASS() to
* initialise the anon transport class storage.
*/
-int anon_transport_class_register(struct anon_transport_class *atc)
+void anon_transport_class_register(struct anon_transport_class *atc)
{
- int error;
atc->container.class = &atc->tclass.class;
attribute_container_set_no_classdevs(&atc->container);
- error = attribute_container_register(&atc->container);
- if (error)
- return error;
+ attribute_container_register(&atc->container);
atc->tclass.setup = anon_transport_dummy_function;
atc->tclass.remove = anon_transport_dummy_function;
- return 0;
}
EXPORT_SYMBOL_GPL(anon_transport_class_register);
diff --git a/drivers/scsi/scsi_transport_spi.c b/drivers/scsi/scsi_transport_spi.c
index fe47850a8258..17a4a0918fc4 100644
--- a/drivers/scsi/scsi_transport_spi.c
+++ b/drivers/scsi/scsi_transport_spi.c
@@ -1622,7 +1622,7 @@ static __init int spi_transport_init(void)
error = transport_class_register(&spi_transport_class);
if (error)
return error;
- error = anon_transport_class_register(&spi_device_class);
+ anon_transport_class_register(&spi_device_class);
return transport_class_register(&spi_host_class);
}
diff --git a/include/linux/attribute_container.h b/include/linux/attribute_container.h
index b3643de9931d..fa6520e192be 100644
--- a/include/linux/attribute_container.h
+++ b/include/linux/attribute_container.h
@@ -36,7 +36,7 @@ attribute_container_set_no_classdevs(struct attribute_container *atc)
atc->flags |= ATTRIBUTE_CONTAINER_NO_CLASSDEVS;
}
-int attribute_container_register(struct attribute_container *cont);
+void attribute_container_register(struct attribute_container *cont);
int __must_check attribute_container_unregister(struct attribute_container *cont);
void attribute_container_create_device(struct device *dev,
int (*fn)(struct attribute_container *,
diff --git a/include/linux/transport_class.h b/include/linux/transport_class.h
index 2efc271a96fa..9c2e03104461 100644
--- a/include/linux/transport_class.h
+++ b/include/linux/transport_class.h
@@ -87,9 +87,9 @@ transport_unregister_device(struct device *dev)
transport_destroy_device(dev);
}
-static inline int transport_container_register(struct transport_container *tc)
+static inline void transport_container_register(struct transport_container *tc)
{
- return attribute_container_register(&tc->ac);
+ attribute_container_register(&tc->ac);
}
static inline void transport_container_unregister(struct transport_container *tc)
@@ -99,7 +99,7 @@ static inline void transport_container_unregister(struct transport_container *tc
}
int transport_class_register(struct transport_class *);
-int anon_transport_class_register(struct anon_transport_class *);
+void anon_transport_class_register(struct anon_transport_class *);
void transport_class_unregister(struct transport_class *);
void anon_transport_class_unregister(struct anon_transport_class *);
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20251218-dev-attribute-container-linux-scsi-ef185a035eba
Best regards,
--
Daniel Gomez <da.gomez@samsung.com>
^ permalink raw reply related
* [PATCH 2/2] scsi: fcoe: replace -EEXIST with -EBUSY
From: Daniel Gomez @ 2025-12-20 3:37 UTC (permalink / raw)
To: Martin K. Petersen, Hannes Reinecke, James E.J. Bottomley
Cc: Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Lucas De Marchi, linux-scsi, target-devel,
linux-modules, linux-kernel, Daniel Gomez
In-Reply-To: <20251220-dev-module-init-eexists-linux-scsi-v1-0-5379db749d54@samsung.com>
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:
* bnx2fc fcoe
Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
drivers/scsi/fcoe/fcoe_transport.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/fcoe/fcoe_transport.c b/drivers/scsi/fcoe/fcoe_transport.c
index 2f478426f16e..d0f9ff4893e3 100644
--- a/drivers/scsi/fcoe/fcoe_transport.c
+++ b/drivers/scsi/fcoe/fcoe_transport.c
@@ -533,7 +533,7 @@ int fcoe_transport_attach(struct fcoe_transport *ft)
if (ft->attached) {
LIBFCOE_TRANSPORT_DBG("transport %s already attached\n",
ft->name);
- rc = -EEXIST;
+ rc = -EBUSY;
goto out_attach;
}
--
2.52.0
^ permalink raw reply related
* [PATCH 1/2] target: replace -EEXIST with -EBUSY
From: Daniel Gomez @ 2025-12-20 3:37 UTC (permalink / raw)
To: Martin K. Petersen, Hannes Reinecke, James E.J. Bottomley
Cc: Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Lucas De Marchi, linux-scsi, target-devel,
linux-modules, linux-kernel, Daniel Gomez
In-Reply-To: <20251220-dev-module-init-eexists-linux-scsi-v1-0-5379db749d54@samsung.com>
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:
* target_core_file target_core_iblock target_core_pscsi
* target_core_user
Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
drivers/target/target_core_hba.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/target/target_core_hba.c b/drivers/target/target_core_hba.c
index d508b343ba7b..dcc11671d919 100644
--- a/drivers/target/target_core_hba.c
+++ b/drivers/target/target_core_hba.c
@@ -50,7 +50,7 @@ int transport_backend_register(const struct target_backend_ops *ops)
pr_err("backend %s already registered.\n", ops->name);
mutex_unlock(&backend_mutex);
kfree(tb);
- return -EEXIST;
+ return -EBUSY;
}
}
target_setup_backend_cits(tb);
--
2.52.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox