modprobe returns 0 upon -EEXIST from insmod

modprobe returns 0 upon -EEXIST from insmod

[Phil Sutter]

Hi,

I admittedly didn't fully analyze the cause, but on my system a call to:

# insmod /lib/module/$(uname -r)/kernel/net/netfilter/nf_conntrack_ftp.ko

fails with -EEXIST (due to a previous call to 'nfct add helper ftp inet
tcp'). A call to:

# modprobe nf_conntrack_ftp

though returns 0 even though module loading fails. Is there a bug in
modprobe error status handling?

Cheers, Phil

Re: modprobe returns 0 upon -EEXIST from insmod

[Christophe Leroy]

Hi,

Le 17/08/2025 à 01:33, Phil Sutter a écrit :
> [Vous ne recevez pas souvent de courriers de phil@nwl.cc. D?couvrez pourquoi ceci est important ? https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hi,
> 
> I admittedly didn't fully analyze the cause, but on my system a call to:
> 
> # insmod /lib/module/$(uname -r)/kernel/net/netfilter/nf_conntrack_ftp.ko
> 
> fails with -EEXIST (due to a previous call to 'nfct add helper ftp inet
> tcp'). A call to:
> 
> # modprobe nf_conntrack_ftp
> 
> though returns 0 even though module loading fails. Is there a bug in
> modprobe error status handling?
> 

Read the man page : https://linux.die.net/man/8/modprobe

In the man page I see:

            Normally, modprobe will succeed (and do nothing) if told to 
insert a module which is already present or to remove a module which 
isn't present.

Christophe

Re: modprobe returns 0 upon -EEXIST from insmod

[Phil Sutter]

Hi Christophe,

On Sun, Aug 17, 2025 at 05:54:27PM +0200, Christophe Leroy wrote:
> Le 17/08/2025 à 01:33, Phil Sutter a écrit :
> > [Vous ne recevez pas souvent de courriers de phil@nwl.cc. D?couvrez pourquoi ceci est important ? https://aka.ms/LearnAboutSenderIdentification ]
> > 
> > Hi,
> > 
> > I admittedly didn't fully analyze the cause, but on my system a call to:
> > 
> > # insmod /lib/module/$(uname -r)/kernel/net/netfilter/nf_conntrack_ftp.ko
> > 
> > fails with -EEXIST (due to a previous call to 'nfct add helper ftp inet
> > tcp'). A call to:
> > 
> > # modprobe nf_conntrack_ftp
> > 
> > though returns 0 even though module loading fails. Is there a bug in
> > modprobe error status handling?
> > 
> 
> Read the man page : https://linux.die.net/man/8/modprobe
> 
> In the man page I see:
> 
>             Normally, modprobe will succeed (and do nothing) if told to 
> insert a module which is already present or to remove a module which 
> isn't present.

This is not a case of already inserted module, it is not loaded before
the call to modprobe. It is the module_init callback
nf_conntrack_ftp_init() which returns -EEXIST it received from
nf_conntrack_helpers_register().

Can't user space distinguish the two causes of -EEXIST? Or in other
words, is use of -EEXIST in module_init callbacks problematic?

Cheers, Phil

Re: modprobe returns 0 upon -EEXIST from insmod

[Christophe Leroy]

[+ Netfilter lists]

Hi Phil

Le 18/08/2025 à 11:34, Phil Sutter a écrit :
> [Vous ne recevez pas souvent de courriers de phil@nwl.cc. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hi Christophe,
> 
> On Sun, Aug 17, 2025 at 05:54:27PM +0200, Christophe Leroy wrote:
>> Le 17/08/2025 à 01:33, Phil Sutter a écrit :
>>> [Vous ne recevez pas souvent de courriers de phil@nwl.cc. D?couvrez pourquoi ceci est important ? https://aka.ms/LearnAboutSenderIdentification ]
>>>
>>> Hi,
>>>
>>> I admittedly didn't fully analyze the cause, but on my system a call to:
>>>
>>> # insmod /lib/module/$(uname -r)/kernel/net/netfilter/nf_conntrack_ftp.ko
>>>
>>> fails with -EEXIST (due to a previous call to 'nfct add helper ftp inet
>>> tcp'). A call to:
>>>
>>> # modprobe nf_conntrack_ftp
>>>
>>> though returns 0 even though module loading fails. Is there a bug in
>>> modprobe error status handling?
>>>
>>
>> Read the man page : https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flinux.die.net%2Fman%2F8%2Fmodprobe&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C34b49eb3d0544fc683e608ddde3a75b2%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638911064858807750%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2F70LV37Zb%2FNeiBV59y9rvkLGh0xsqga08Nl3c5%2BVU5I%3D&reserved=0
>>
>> In the man page I see:
>>
>>              Normally, modprobe will succeed (and do nothing) if told to
>> insert a module which is already present or to remove a module which
>> isn't present.
> 
> This is not a case of already inserted module, it is not loaded before
> the call to modprobe. It is the module_init callback
> nf_conntrack_ftp_init() which returns -EEXIST it received from
> nf_conntrack_helpers_register().
> 
> Can't user space distinguish the two causes of -EEXIST? Or in other
> words, is use of -EEXIST in module_init callbacks problematic?

So if I understand correctly the load fails because it is in conflict 
with another module ?

Then I think the error returned by nf_conntrack_helpers_register() 
shouldn't be EEXIST but probably EBUSY.

Christophe

Re: modprobe returns 0 upon -EEXIST from insmod

[Phil Sutter]

On Mon, Aug 18, 2025 at 12:07:18PM +0200, Christophe Leroy wrote:
> [+ Netfilter lists]
> 
> Hi Phil
> 
> Le 18/08/2025 à 11:34, Phil Sutter a écrit :
> > [Vous ne recevez pas souvent de courriers de phil@nwl.cc. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
> > 
> > Hi Christophe,
> > 
> > On Sun, Aug 17, 2025 at 05:54:27PM +0200, Christophe Leroy wrote:
> >> Le 17/08/2025 à 01:33, Phil Sutter a écrit :
> >>> [Vous ne recevez pas souvent de courriers de phil@nwl.cc. D?couvrez pourquoi ceci est important ? https://aka.ms/LearnAboutSenderIdentification ]
> >>>
> >>> Hi,
> >>>
> >>> I admittedly didn't fully analyze the cause, but on my system a call to:
> >>>
> >>> # insmod /lib/module/$(uname -r)/kernel/net/netfilter/nf_conntrack_ftp.ko
> >>>
> >>> fails with -EEXIST (due to a previous call to 'nfct add helper ftp inet
> >>> tcp'). A call to:
> >>>
> >>> # modprobe nf_conntrack_ftp
> >>>
> >>> though returns 0 even though module loading fails. Is there a bug in
> >>> modprobe error status handling?
> >>>
> >>
> >> Read the man page : https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flinux.die.net%2Fman%2F8%2Fmodprobe&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C34b49eb3d0544fc683e608ddde3a75b2%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638911064858807750%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2F70LV37Zb%2FNeiBV59y9rvkLGh0xsqga08Nl3c5%2BVU5I%3D&reserved=0
> >>
> >> In the man page I see:
> >>
> >>              Normally, modprobe will succeed (and do nothing) if told to
> >> insert a module which is already present or to remove a module which
> >> isn't present.
> > 
> > This is not a case of already inserted module, it is not loaded before
> > the call to modprobe. It is the module_init callback
> > nf_conntrack_ftp_init() which returns -EEXIST it received from
> > nf_conntrack_helpers_register().
> > 
> > Can't user space distinguish the two causes of -EEXIST? Or in other
> > words, is use of -EEXIST in module_init callbacks problematic?
> 
> So if I understand correctly the load fails because it is in conflict 
> with another module ?

Yes, it tries to signal that there is already a conntrack helper for
FTP. It is a stub redirecting to an implementation in user space, but
that's just details.

> Then I think the error returned by nf_conntrack_helpers_register() 
> shouldn't be EEXIST but probably EBUSY.

Sounds good! We could at least adjust the module_init callback return
code from EEXIST to EBUSY so the change has minimal impact.

Thanks for your help, Christophe!

Cheers, Phil

Re: modprobe returns 0 upon -EEXIST from insmod

[Petr Pavlu]

On 8/18/25 11:34 AM, Phil Sutter wrote:
> On Sun, Aug 17, 2025 at 05:54:27PM +0200, Christophe Leroy wrote:
>> Le 17/08/2025 à 01:33, Phil Sutter a écrit :
>>> [Vous ne recevez pas souvent de courriers de phil@nwl.cc. D?couvrez pourquoi ceci est important ? https://aka.ms/LearnAboutSenderIdentification ]
>>>
>>> Hi,
>>>
>>> I admittedly didn't fully analyze the cause, but on my system a call to:
>>>
>>> # insmod /lib/module/$(uname -r)/kernel/net/netfilter/nf_conntrack_ftp.ko
>>>
>>> fails with -EEXIST (due to a previous call to 'nfct add helper ftp inet
>>> tcp'). A call to:
>>>
>>> # modprobe nf_conntrack_ftp
>>>
>>> though returns 0 even though module loading fails. Is there a bug in
>>> modprobe error status handling?
>>>
>>
>> Read the man page : https://linux.die.net/man/8/modprobe
>>
>> In the man page I see:
>>
>>             Normally, modprobe will succeed (and do nothing) if told to 
>> insert a module which is already present or to remove a module which 
>> isn't present.
> 
> This is not a case of already inserted module, it is not loaded before
> the call to modprobe. It is the module_init callback
> nf_conntrack_ftp_init() which returns -EEXIST it received from
> nf_conntrack_helpers_register().
> 
> Can't user space distinguish the two causes of -EEXIST? Or in other
> words, is use of -EEXIST in module_init callbacks problematic?

Unfortunately, error return codes from (f)init_module cannot be reliably
depended upon. For instance, cpufreq drivers have similar behavior of
returning -EEXIST when another cpufreq driver is already registered.
Returning this code unexpectedly can then confuse kmod, as it interprets
-EEXIST to mean "the module is already loaded" [1].

I have thought about this problem before. We might fix the main
problematic occurrences, but we can't really audit all the code that
module init functions can invoke. I then wonder if it would make sense
for the module loader to warn about any -EEXIST returned by a module's
init function and translate it to -EBUSY.

Ensuring the reliability of the 0 and -EEXIST return codes from
(f)init_module should help user space.

[1] https://github.com/kmod-project/kmod/blob/695fd084a727cf76f51b129b67d5a4be1d6db32e/libkmod/libkmod-module.c#L1087

-- Petr

Re: modprobe returns 0 upon -EEXIST from insmod

[Lucas De Marchi]

On Tue, Aug 19, 2025 at 10:52:16AM +0200, Petr Pavlu wrote:
>On 8/18/25 11:34 AM, Phil Sutter wrote:
>> On Sun, Aug 17, 2025 at 05:54:27PM +0200, Christophe Leroy wrote:
>>> Le 17/08/2025 à 01:33, Phil Sutter a écrit :
>>>> [Vous ne recevez pas souvent de courriers de phil@nwl.cc. D?couvrez pourquoi ceci est important ? https://aka.ms/LearnAboutSenderIdentification ]
>>>>
>>>> Hi,
>>>>
>>>> I admittedly didn't fully analyze the cause, but on my system a call to:
>>>>
>>>> # insmod /lib/module/$(uname -r)/kernel/net/netfilter/nf_conntrack_ftp.ko
>>>>
>>>> fails with -EEXIST (due to a previous call to 'nfct add helper ftp inet
>>>> tcp'). A call to:
>>>>
>>>> # modprobe nf_conntrack_ftp
>>>>
>>>> though returns 0 even though module loading fails. Is there a bug in
>>>> modprobe error status handling?
>>>>
>>>
>>> Read the man page : https://linux.die.net/man/8/modprobe
>>>
>>> In the man page I see:
>>>
>>>             Normally, modprobe will succeed (and do nothing) if told to
>>> insert a module which is already present or to remove a module which
>>> isn't present.
>>
>> This is not a case of already inserted module, it is not loaded before
>> the call to modprobe. It is the module_init callback
>> nf_conntrack_ftp_init() which returns -EEXIST it received from
>> nf_conntrack_helpers_register().

is this a real failure condition or something benign like "if it's
already registered, there's nothing to do"?

>>
>> Can't user space distinguish the two causes of -EEXIST? Or in other
>> words, is use of -EEXIST in module_init callbacks problematic?
>
>Unfortunately, error return codes from (f)init_module cannot be reliably
>depended upon. For instance, cpufreq drivers have similar behavior of
>returning -EEXIST when another cpufreq driver is already registered.
>Returning this code unexpectedly can then confuse kmod, as it interprets
>-EEXIST to mean "the module is already loaded" [1].

well, it's not that it can't be relied on. There's 1 exit code that is
treated specially, EEXISTS, because that error is used by the module
loading part, before the module_init call, to signify the module is
already loaded.

>
>I have thought about this problem before. We might fix the main
>problematic occurrences, but we can't really audit all the code that
>module init functions can invoke. I then wonder if it would make sense
>for the module loader to warn about any -EEXIST returned by a module's
>init function and translate it to -EBUSY.

If it's a failure condition then yes, -EBUSY looks appropriate.

Lucas De Marchi

>
>Ensuring the reliability of the 0 and -EEXIST return codes from
>(f)init_module should help user space.
>
>[1] https://github.com/kmod-project/kmod/blob/695fd084a727cf76f51b129b67d5a4be1d6db32e/libkmod/libkmod-module.c#L1087
>
>-- Petr

Re: modprobe returns 0 upon -EEXIST from insmod

[Christophe Leroy]

Le 19/08/2025 à 16:17, Lucas De Marchi a écrit :
> On Tue, Aug 19, 2025 at 10:52:16AM +0200, Petr Pavlu wrote:
>> On 8/18/25 11:34 AM, Phil Sutter wrote:
>>> On Sun, Aug 17, 2025 at 05:54:27PM +0200, Christophe Leroy wrote:
>>>> Le 17/08/2025 à 01:33, Phil Sutter a écrit :
>>>>> [Vous ne recevez pas souvent de courriers de phil@nwl.cc. D?couvrez 
>>>>> pourquoi ceci est important ? https://aka.ms/ 
>>>>> LearnAboutSenderIdentification ]
>>>>>
>>>>> Hi,
>>>>>
>>>>> I admittedly didn't fully analyze the cause, but on my system a 
>>>>> call to:
>>>>>
>>>>> # insmod /lib/module/$(uname -r)/kernel/net/netfilter/ 
>>>>> nf_conntrack_ftp.ko
>>>>>
>>>>> fails with -EEXIST (due to a previous call to 'nfct add helper ftp 
>>>>> inet
>>>>> tcp'). A call to:
>>>>>
>>>>> # modprobe nf_conntrack_ftp
>>>>>
>>>>> though returns 0 even though module loading fails. Is there a bug in
>>>>> modprobe error status handling?
>>>>>
>>>>
>>>> Read the man page : https://eur01.safelinks.protection.outlook.com/? 
>>>> url=https%3A%2F%2Flinux.die.net%2Fman%2F8%2Fmodprobe&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C2c842a011e454a06da1708dddf2b37a7%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638912098887559261%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=QFjpi0HYpLQjzCxuNLgEtq44XzUbyKy8VRAGec5H7Ok%3D&reserved=0
>>>>
>>>> In the man page I see:
>>>>
>>>>             Normally, modprobe will succeed (and do nothing) if told to
>>>> insert a module which is already present or to remove a module which
>>>> isn't present.
>>>
>>> This is not a case of already inserted module, it is not loaded before
>>> the call to modprobe. It is the module_init callback
>>> nf_conntrack_ftp_init() which returns -EEXIST it received from
>>> nf_conntrack_helpers_register().
> 
> is this a real failure condition or something benign like "if it's
> already registered, there's nothing to do"?

My understanding from Phil's explanation is: it is something serious 
that says something like "There is already something else registered on 
that UDP Port, I can't register the conntrack helper on that port".

Christophe

> 
>>>
>>> Can't user space distinguish the two causes of -EEXIST? Or in other
>>> words, is use of -EEXIST in module_init callbacks problematic?
>>
>> Unfortunately, error return codes from (f)init_module cannot be reliably
>> depended upon. For instance, cpufreq drivers have similar behavior of
>> returning -EEXIST when another cpufreq driver is already registered.
>> Returning this code unexpectedly can then confuse kmod, as it interprets
>> -EEXIST to mean "the module is already loaded" [1].
> 
> well, it's not that it can't be relied on. There's 1 exit code that is
> treated specially, EEXISTS, because that error is used by the module
> loading part, before the module_init call, to signify the module is
> already loaded.
> 
>>
>> I have thought about this problem before. We might fix the main
>> problematic occurrences, but we can't really audit all the code that
>> module init functions can invoke. I then wonder if it would make sense
>> for the module loader to warn about any -EEXIST returned by a module's
>> init function and translate it to -EBUSY.
> 
> If it's a failure condition then yes, -EBUSY looks appropriate.
> 
> Lucas De Marchi
> 
>>
>> Ensuring the reliability of the 0 and -EEXIST return codes from
>> (f)init_module should help user space.
>>
>> [1] https://eur01.safelinks.protection.outlook.com/? 
>> url=https%3A%2F%2Fgithub.com%2Fkmod- 
>> project%2Fkmod%2Fblob%2F695fd084a727cf76f51b129b67d5a4be1d6db32e%2Flibkmod%2Flibkmod-module.c%23L1087&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C2c842a011e454a06da1708dddf2b37a7%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638912098887579771%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=A2B0UH9D47p53Jif4ppLAaiDl6MDIX6ZFjUNik5Cmis%3D&reserved=0
>>
>> -- Petr

Re: modprobe returns 0 upon -EEXIST from insmod

[Lucas De Marchi]

On Tue, Aug 19, 2025 at 09:17:50AM -0500, Lucas De Marchi wrote:
>On Tue, Aug 19, 2025 at 10:52:16AM +0200, Petr Pavlu wrote:
>>On 8/18/25 11:34 AM, Phil Sutter wrote:
>>>On Sun, Aug 17, 2025 at 05:54:27PM +0200, Christophe Leroy wrote:
>>>>Le 17/08/2025 à 01:33, Phil Sutter a écrit :
>>>>>[Vous ne recevez pas souvent de courriers de phil@nwl.cc. D?couvrez pourquoi ceci est important ? https://aka.ms/LearnAboutSenderIdentification ]
>>>>>
>>>>>Hi,
>>>>>
>>>>>I admittedly didn't fully analyze the cause, but on my system a call to:
>>>>>
>>>>># insmod /lib/module/$(uname -r)/kernel/net/netfilter/nf_conntrack_ftp.ko
>>>>>
>>>>>fails with -EEXIST (due to a previous call to 'nfct add helper ftp inet
>>>>>tcp'). A call to:
>>>>>
>>>>># modprobe nf_conntrack_ftp
>>>>>
>>>>>though returns 0 even though module loading fails. Is there a bug in
>>>>>modprobe error status handling?
>>>>>
>>>>
>>>>Read the man page : https://linux.die.net/man/8/modprobe
>>>>
>>>>In the man page I see:
>>>>
>>>>            Normally, modprobe will succeed (and do nothing) if told to
>>>>insert a module which is already present or to remove a module which
>>>>isn't present.
>>>
>>>This is not a case of already inserted module, it is not loaded before
>>>the call to modprobe. It is the module_init callback
>>>nf_conntrack_ftp_init() which returns -EEXIST it received from
>>>nf_conntrack_helpers_register().
>
>is this a real failure condition or something benign like "if it's
>already registered, there's nothing to do"?
>
>>>
>>>Can't user space distinguish the two causes of -EEXIST? Or in other
>>>words, is use of -EEXIST in module_init callbacks problematic?
>>
>>Unfortunately, error return codes from (f)init_module cannot be reliably
>>depended upon. For instance, cpufreq drivers have similar behavior of
>>returning -EEXIST when another cpufreq driver is already registered.
>>Returning this code unexpectedly can then confuse kmod, as it interprets
>>-EEXIST to mean "the module is already loaded" [1].
>
>well, it's not that it can't be relied on. There's 1 exit code that is
>treated specially, EEXISTS, because that error is used by the module
>loading part, before the module_init call, to signify the module is
>already loaded.
>
>>
>>I have thought about this problem before. We might fix the main
>>problematic occurrences, but we can't really audit all the code that
>>module init functions can invoke. I then wonder if it would make sense
>>for the module loader to warn about any -EEXIST returned by a module's
>>init function and translate it to -EBUSY.
>
>If it's a failure condition then yes, -EBUSY looks appropriate.

something like this:


diff --git a/kernel/module/main.c b/kernel/module/main.c
index c66b261849362..e5fb1a4ef3441 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -3038,6 +3038,11 @@ static noinline int do_init_module(struct module *mod)
  	if (mod->init != NULL)
  		ret = do_one_initcall(mod->init);
  	if (ret < 0) {
+		if (ret == -EEXIST) {
+			pr_warn("%s: '%s'->init suspiciously returned %d: Overriding with %d\n",
+				__func__, mod->name, -EEXIST, -EBUSY);
+			ret = -EBUSY;
+		}
  		goto fail_free_freeinit;
  	}
  	if (ret > 0) {

Lucas De Marchi

>
>Lucas De Marchi
>
>>
>>Ensuring the reliability of the 0 and -EEXIST return codes from
>>(f)init_module should help user space.
>>
>>[1] https://github.com/kmod-project/kmod/blob/695fd084a727cf76f51b129b67d5a4be1d6db32e/libkmod/libkmod-module.c#L1087
>>
>>-- Petr

Re: modprobe returns 0 upon -EEXIST from insmod

[Petr Pavlu]

On 10/8/25 8:41 AM, Lucas De Marchi wrote:
> On Tue, Aug 19, 2025 at 09:17:50AM -0500, Lucas De Marchi wrote:
>> On Tue, Aug 19, 2025 at 10:52:16AM +0200, Petr Pavlu wrote:
>>> On 8/18/25 11:34 AM, Phil Sutter wrote:
>>>> On Sun, Aug 17, 2025 at 05:54:27PM +0200, Christophe Leroy wrote:
>>>>> Le 17/08/2025 à 01:33, Phil Sutter a écrit :
>>>>>> [Vous ne recevez pas souvent de courriers de phil@nwl.cc. D?couvrez pourquoi ceci est important ? https://aka.ms/LearnAboutSenderIdentification ]
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I admittedly didn't fully analyze the cause, but on my system a call to:
>>>>>>
>>>>>> # insmod /lib/module/$(uname -r)/kernel/net/netfilter/nf_conntrack_ftp.ko
>>>>>>
>>>>>> fails with -EEXIST (due to a previous call to 'nfct add helper ftp inet
>>>>>> tcp'). A call to:
>>>>>>
>>>>>> # modprobe nf_conntrack_ftp
>>>>>>
>>>>>> though returns 0 even though module loading fails. Is there a bug in
>>>>>> modprobe error status handling?
>>>>>>
>>>>>
>>>>> Read the man page : https://linux.die.net/man/8/modprobe
>>>>>
>>>>> In the man page I see:
>>>>>
>>>>>            Normally, modprobe will succeed (and do nothing) if told to
>>>>> insert a module which is already present or to remove a module which
>>>>> isn't present.
>>>>
>>>> This is not a case of already inserted module, it is not loaded before
>>>> the call to modprobe. It is the module_init callback
>>>> nf_conntrack_ftp_init() which returns -EEXIST it received from
>>>> nf_conntrack_helpers_register().
>>
>> is this a real failure condition or something benign like "if it's
>> already registered, there's nothing to do"?
>>
>>>>
>>>> Can't user space distinguish the two causes of -EEXIST? Or in other
>>>> words, is use of -EEXIST in module_init callbacks problematic?
>>>
>>> Unfortunately, error return codes from (f)init_module cannot be reliably
>>> depended upon. For instance, cpufreq drivers have similar behavior of
>>> returning -EEXIST when another cpufreq driver is already registered.
>>> Returning this code unexpectedly can then confuse kmod, as it interprets
>>> -EEXIST to mean "the module is already loaded" [1].
>>
>> well, it's not that it can't be relied on. There's 1 exit code that is
>> treated specially, EEXISTS, because that error is used by the module
>> loading part, before the module_init call, to signify the module is
>> already loaded.
>>
>>>
>>> I have thought about this problem before. We might fix the main
>>> problematic occurrences, but we can't really audit all the code that
>>> module init functions can invoke. I then wonder if it would make sense
>>> for the module loader to warn about any -EEXIST returned by a module's
>>> init function and translate it to -EBUSY.
>>
>> If it's a failure condition then yes, -EBUSY looks appropriate.
> 
> something like this:
> 
> 
> diff --git a/kernel/module/main.c b/kernel/module/main.c
> index c66b261849362..e5fb1a4ef3441 100644
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c
> @@ -3038,6 +3038,11 @@ static noinline int do_init_module(struct module *mod)
>      if (mod->init != NULL)
>          ret = do_one_initcall(mod->init);
>      if (ret < 0) {
> +        if (ret == -EEXIST) {
> +            pr_warn("%s: '%s'->init suspiciously returned %d: Overriding with %d\n",
> +                __func__, mod->name, -EEXIST, -EBUSY);
> +            ret = -EBUSY;
> +        }
>          goto fail_free_freeinit;
>      }
>      if (ret > 0) {

Yes, that's what I had in mind. Could you please send this as a proper
patch to the list?

I only think we should include a hint to explain why this is a problem
and simplify the message somewhat, something like:

pr_warn("%s: init suspiciously returned -EEXIST (reserved for loaded modules), overriding with -EBUSY\n", mod->name);

I realize you based the message on the later warning about the init
function returning a >0 value but I think we should rather update that
message as well. It should follow the usual style of
"<mod-name>: <error-description>". I suggest simplifying it to:

pr_warn("%s: init suspiciously returned %d, it should follow 0/-E convention\n", mod->name, ret);

-- 
Thanks,
Petr

Re: modprobe returns 0 upon -EEXIST from insmod

[Lucas De Marchi]

On Thu, Oct 09, 2025 at 03:47:42PM +0200, Petr Pavlu wrote:
>On 10/8/25 8:41 AM, Lucas De Marchi wrote:
>> On Tue, Aug 19, 2025 at 09:17:50AM -0500, Lucas De Marchi wrote:
>>> On Tue, Aug 19, 2025 at 10:52:16AM +0200, Petr Pavlu wrote:
>>>> On 8/18/25 11:34 AM, Phil Sutter wrote:
>>>>> On Sun, Aug 17, 2025 at 05:54:27PM +0200, Christophe Leroy wrote:
>>>>>> Le 17/08/2025 à 01:33, Phil Sutter a écrit :
>>>>>>> [Vous ne recevez pas souvent de courriers de phil@nwl.cc. D?couvrez pourquoi ceci est important ? https://aka.ms/LearnAboutSenderIdentification ]
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I admittedly didn't fully analyze the cause, but on my system a call to:
>>>>>>>
>>>>>>> # insmod /lib/module/$(uname -r)/kernel/net/netfilter/nf_conntrack_ftp.ko
>>>>>>>
>>>>>>> fails with -EEXIST (due to a previous call to 'nfct add helper ftp inet
>>>>>>> tcp'). A call to:
>>>>>>>
>>>>>>> # modprobe nf_conntrack_ftp
>>>>>>>
>>>>>>> though returns 0 even though module loading fails. Is there a bug in
>>>>>>> modprobe error status handling?
>>>>>>>
>>>>>>
>>>>>> Read the man page : https://linux.die.net/man/8/modprobe
>>>>>>
>>>>>> In the man page I see:
>>>>>>
>>>>>>            Normally, modprobe will succeed (and do nothing) if told to
>>>>>> insert a module which is already present or to remove a module which
>>>>>> isn't present.
>>>>>
>>>>> This is not a case of already inserted module, it is not loaded before
>>>>> the call to modprobe. It is the module_init callback
>>>>> nf_conntrack_ftp_init() which returns -EEXIST it received from
>>>>> nf_conntrack_helpers_register().
>>>
>>> is this a real failure condition or something benign like "if it's
>>> already registered, there's nothing to do"?
>>>
>>>>>
>>>>> Can't user space distinguish the two causes of -EEXIST? Or in other
>>>>> words, is use of -EEXIST in module_init callbacks problematic?
>>>>
>>>> Unfortunately, error return codes from (f)init_module cannot be reliably
>>>> depended upon. For instance, cpufreq drivers have similar behavior of
>>>> returning -EEXIST when another cpufreq driver is already registered.
>>>> Returning this code unexpectedly can then confuse kmod, as it interprets
>>>> -EEXIST to mean "the module is already loaded" [1].
>>>
>>> well, it's not that it can't be relied on. There's 1 exit code that is
>>> treated specially, EEXISTS, because that error is used by the module
>>> loading part, before the module_init call, to signify the module is
>>> already loaded.
>>>
>>>>
>>>> I have thought about this problem before. We might fix the main
>>>> problematic occurrences, but we can't really audit all the code that
>>>> module init functions can invoke. I then wonder if it would make sense
>>>> for the module loader to warn about any -EEXIST returned by a module's
>>>> init function and translate it to -EBUSY.
>>>
>>> If it's a failure condition then yes, -EBUSY looks appropriate.
>>
>> something like this:
>>
>>
>> diff --git a/kernel/module/main.c b/kernel/module/main.c
>> index c66b261849362..e5fb1a4ef3441 100644
>> --- a/kernel/module/main.c
>> +++ b/kernel/module/main.c
>> @@ -3038,6 +3038,11 @@ static noinline int do_init_module(struct module *mod)
>>      if (mod->init != NULL)
>>          ret = do_one_initcall(mod->init);
>>      if (ret < 0) {
>> +        if (ret == -EEXIST) {
>> +            pr_warn("%s: '%s'->init suspiciously returned %d: Overriding with %d\n",
>> +                __func__, mod->name, -EEXIST, -EBUSY);
>> +            ret = -EBUSY;
>> +        }
>>          goto fail_free_freeinit;
>>      }
>>      if (ret > 0) {
>
>Yes, that's what I had in mind. Could you please send this as a proper
>patch to the list?
>
>I only think we should include a hint to explain why this is a problem
>and simplify the message somewhat, something like:
>
>pr_warn("%s: init suspiciously returned -EEXIST (reserved for loaded modules), overriding with -EBUSY\n", mod->name);
>
>I realize you based the message on the later warning about the init
>function returning a >0 value but I think we should rather update that
>message as well. It should follow the usual style of
>"<mod-name>: <error-description>". I suggest simplifying it to:
>
>pr_warn("%s: init suspiciously returned %d, it should follow 0/-E convention\n", mod->name, ret);

will do and actually run some tests to make sure it's not only
build-tested.

Thanks,
Lucas De Marchi

>
>-- 
>Thanks,
>Petr