netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 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).