* Re: modprobe returns 0 upon -EEXIST from insmod
[not found] ` <aKLzsAX14ybEjHfJ@orbyte.nwl.cc>
@ 2025-08-18 10:07 ` Christophe Leroy
2025-08-18 10:56 ` Phil Sutter
0 siblings, 1 reply; 2+ messages in thread
From: Christophe Leroy @ 2025-08-18 10:07 UTC (permalink / raw)
To: Phil Sutter, netfilter-devel, coreteam; +Cc: linux-modules, Yi Chen, netdev
[+ 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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: modprobe returns 0 upon -EEXIST from insmod
2025-08-18 10:07 ` modprobe returns 0 upon -EEXIST from insmod Christophe Leroy
@ 2025-08-18 10:56 ` Phil Sutter
0 siblings, 0 replies; 2+ messages in thread
From: Phil Sutter @ 2025-08-18 10:56 UTC (permalink / raw)
To: Christophe Leroy
Cc: netfilter-devel, coreteam, linux-modules, Yi Chen, netdev
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2025-08-18 10:56 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <aKEVQhJpRdiZSliu@orbyte.nwl.cc>
[not found] ` <8a87656d-577a-4d0a-85b1-5fd17d0346fe@csgroup.eu>
[not found] ` <aKLzsAX14ybEjHfJ@orbyte.nwl.cc>
2025-08-18 10:07 ` modprobe returns 0 upon -EEXIST from insmod Christophe Leroy
2025-08-18 10:56 ` Phil Sutter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).