latest pom: base/connlimit breaks kernel 2.4.25 compile (+possible fix)

latest pom: base/connlimit breaks kernel 2.4.25 compile (+possible fix)

[Friedrich Lobenstock]

[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]

Hi!

Applying the latest pom-20040409 to kernel 2.4.25 breaks the compile:

gcc -D__KERNEL__ -I/data/build/tmp/linux-2.4.25/include -Wall 
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common 
-fomit-frame-pointer  -pipe -mpreferred-stack-boundary=2 -march
=i586 -DMODULE -DMODVERSIONS -include 
/data/build/tmp/linux-2.4.25/include/linux/modversions.h  -nostdinc 
-iwithprefix include -DKBUILD_BASENAME=ipt_connlimit  -c -o ipt_connlimit.o 
ipt_connlimit.c
ipt_connlimit.c: In function `init':
ipt_connlimit.c:219: error: `ip_conntrack_module' undeclared (first use in 
this function)
ipt_connlimit.c:219: error: (Each undeclared identifier is reported only once
ipt_connlimit.c:219: error: for each function it appears in.)
ipt_connlimit.c:220: warning: value computed is not used
ipt_connlimit.c: In function `fini':
ipt_connlimit.c:227: error: `ip_conntrack_module' undeclared (first use in 
this function)
ipt_connlimit.c:228: warning: value computed is not used
make[3]: *** [ipt_connlimit.o] Error 1
make[3]: Leaving directory `/data/build/tmp/linux-2.4.25/net/ipv4/netfilter'
make[2]: *** [_modsubdir_ipv4/netfilter] Error 2
make[2]: Leaving directory `/data/build/tmp/linux-2.4.25/net'
make[1]: *** [_mod_net] Error 2
make[1]: Leaving directory `/data/build/tmp/linux-2.4.25'

I was woundering if the correct way to fix this is to create the
   struct module *ip_connlimit_module
variable in ipt_connlimit.c and use it instead of the undefined
variable "ip_conntrack_module". See also attached patch for how
I think I would do it.

What do you think?

-- 
MfG / Regards
Friedrich Lobenstock

[-- Attachment #2: patch-broken-ipt_connlimit.c --]
[-- Type: text/plain, Size: 956 bytes --]

--- linux-2.4.25/net/ipv4/netfilter/ipt_connlimit.c.broken	2004-04-10 17:01:40.000000000 +0200
+++ linux-2.4.25/net/ipv4/netfilter/ipt_connlimit.c	2004-04-10 17:02:18.000000000 +0200
@@ -23,6 +23,8 @@
 
 MODULE_LICENSE("GPL");
 
+struct module *ip_connlimit_module = THIS_MODULE;
+
 /* we'll save the tuples of all connections we care about */
 struct ipt_connlimit_conn
 {
@@ -215,17 +217,17 @@
 
 static int __init init(void)
 {
-	/* NULL if ip_conntrack not a module */
-	if (ip_conntrack_module)
-		__MOD_INC_USE_COUNT(ip_conntrack_module);
+	/* NULL if ip_connlimit not a module */
+	if (ip_connlimit_module)
+		__MOD_INC_USE_COUNT(ip_connlimit_module);
 	return ipt_register_match(&connlimit_match);
 }
 
 static void __exit fini(void)
 {
 	ipt_unregister_match(&connlimit_match);
-	if (ip_conntrack_module)
-		__MOD_DEC_USE_COUNT(ip_conntrack_module);
+	if (ip_connlimit_module)
+		__MOD_DEC_USE_COUNT(ip_connlimit_module);
 }
 
 module_init(init);

Re: latest pom: base/connlimit breaks kernel 2.4.25 compile (+possible fix)

[Pablo Neira]

Hi Friedrich,

Friedrich Lobenstock wrote:

>-	/* NULL if ip_conntrack not a module */
>-	if (ip_conntrack_module)
>-		__MOD_INC_USE_COUNT(ip_conntrack_module);
>+	/* NULL if ip_connlimit not a module */
>+	if (ip_connlimit_module)
>+		__MOD_INC_USE_COUNT(ip_connlimit_module);
> 	return ipt_register_match(&connlimit_match);
> }
>
>  
>
AFAIK, the use of __MOD_INC_USE_COUNT is deprecated, actually I remember 
that someone posted to the maillist a related issue and Harald finally 
decided to remove them. If I'm missing anything, please let me know.

So I think that you could remove them, you could also post a patch to 
update the current match available in pom-ng :-).

regards,
Pablo

Re: latest pom: base/connlimit breaks kernel 2.4.25 compile (+possible fix)

[Friedrich Lobenstock]

Hi Pablo!

Pablo Neira wrote on 10.04.2004 18:52 MET:
> Friedrich Lobenstock wrote:
> 
>> -    /* NULL if ip_conntrack not a module */
>> -    if (ip_conntrack_module)
>> -        __MOD_INC_USE_COUNT(ip_conntrack_module);
>> +    /* NULL if ip_connlimit not a module */
>> +    if (ip_connlimit_module)
>> +        __MOD_INC_USE_COUNT(ip_connlimit_module);
>>     return ipt_register_match(&connlimit_match);
>> }
>>
>>  
>
> AFAIK, the use of __MOD_INC_USE_COUNT is deprecated, actually I remember 
> that someone posted to the maillist a related issue and Harald finally 
> decided to remove them. If I'm missing anything, please let me know.

Hmmmm....I just looked at other modules to see how they do it, so 
__MOD_INC_USE_COUNT() still seems to be in use not only in this module.

> So I think that you could remove them, you could also post a patch to 
> update the current match available in pom-ng :-).

Can I really remove those lines completely?

-- 
MfG / Regards
Friedrich Lobenstock

Re: latest pom: base/connlimit breaks kernel 2.4.25 compile (+possible fix)

[Henrik Nordstrom]

On Sat, 10 Apr 2004, Friedrich Lobenstock wrote:

> Hmmmm....I just looked at other modules to see how they do it, so 
> __MOD_INC_USE_COUNT() still seems to be in use not only in this module.

It was common practice some years ago, mostly because of a 
misunderstanding in how module dependencies works..

> Can I really remove those lines completely?

Yes. The connlimit module already depends on conntrack by the calls to
functions within conntrack.

Regards
Henrik

Re: latest pom: base/connlimit breaks kernel 2.4.25 compile (+possible fix)

[Friedrich Lobenstock]

Henrik Nordstrom wrote on 11.04.2004 01:58 MET:
> On Sat, 10 Apr 2004, Friedrich Lobenstock wrote:
> 
>>Can I really remove those lines completely?
> 
> Yes. The connlimit module already depends on conntrack by the calls to
> functions within conntrack.

Ok. So what do you want then? A corrected patch or a patch for the patch?

-- 
MfG / Regards
Friedrich Lobenstock

Re: latest pom: base/connlimit breaks kernel 2.4.25 compile (+possible fix)

[Henrik Nordstrom]

On Sun, 11 Apr 2004, Friedrich Lobenstock wrote:

> > Yes. The connlimit module already depends on conntrack by the calls to
> > functions within conntrack.
> 
> Ok. So what do you want then? A corrected patch or a patch for the patch?

I think the core people wants a patch to what currently is in pom-ng, 
replacing any earlier patches.

Regards
Henrik

Re: latest pom: base/connlimit breaks kernel 2.4.25 compile (+possible fix)

[Friedrich Lobenstock]

Henrik Nordstrom wrote on 11.04.2004 12:39 MET:
> On Sun, 11 Apr 2004, Friedrich Lobenstock wrote:
> 
> 
>>>Yes. The connlimit module already depends on conntrack by the calls to
>>>functions within conntrack.
>>
>>Ok. So what do you want then? A corrected patch or a patch for the patch?
> 
> 
> I think the core people wants a patch to what currently is in pom-ng, 
> replacing any earlier patches.

Hmmmm....I am using plain pom, not pom-ng. So is this abandoned and not 
maintained anymore?

-- 
MfG / Regards
Friedrich Lobenstock

Re: latest pom: base/connlimit breaks kernel 2.4.25 compile (+possible fix)

[Henrik Nordstrom]

On Sun, 11 Apr 2004, Friedrich Lobenstock wrote:

> > I think the core people wants a patch to what currently is in pom-ng, 
> > replacing any earlier patches.
> 
> Hmmmm....I am using plain pom, not pom-ng. So is this abandoned and not 
> maintained anymore?

The development has fully switched over to pom-ng, and there will not be 
any new versions of the older pom published from what I can understand.

pom-ng contains a superset of the extensions which was found in pom.

Regards
Henrik

Re: latest pom: base/connlimit breaks kernel 2.4.25 compile (+possible fix)

[Friedrich Lobenstock]

Henrik Nordstrom wrote on 11.04.2004 22:47 MET:
> On Sun, 11 Apr 2004, Friedrich Lobenstock wrote:
> 
> 
>>>I think the core people wants a patch to what currently is in pom-ng, 
>>>replacing any earlier patches.
>>
>>Hmmmm....I am using plain pom, not pom-ng. So is this abandoned and not 
>>maintained anymore?
> 
> 
> The development has fully switched over to pom-ng, and there will not be 
> any new versions of the older pom published from what I can understand.

As far as I see there are still daily pom snapshots created so it
can't be dead.

> pom-ng contains a superset of the extensions which was found in pom.

How about stability pom compared to pom-ng? It was "only" released the 
first time in March, so I think for the time beeing I will have to stay 
with good old "normal" pom.

-- 
MfG / Regards
Friedrich Lobenstock

Re: latest pom: base/connlimit breaks kernel 2.4.25 compile (+possible fix)

[Henrik Nordstrom]

On Sun, 11 Apr 2004, Friedrich Lobenstock wrote:

> > The development has fully switched over to pom-ng, and there will not be 
> > any new versions of the older pom published from what I can understand.
> 
> As far as I see there are still daily pom snapshots created so it
> can't be dead.

A cron job making daily snapshots does not make a tree alive.. developers 
working on a tree is the only thing which makes a tree alive.

> > pom-ng contains a superset of the extensions which was found in pom.
> 
> How about stability pom compared to pom-ng? It was "only" released the 
> first time in March, so I think for the time beeing I will have to stay 
> with good old "normal" pom.

pom-ng is the natural continuation of pom. It applies all the extensions
in the same manner, only that some of the extensions is newer and the
internal format of how patches/extensions is stored is very different.  
The majority of the pom-ng extensions is direct syntax translations from
their equivalent pom patches, and then improved upon. But yes the pom-ng
framework is still being worked upon to make it even more powerful, which
sometimes means there may be bugs in the framework.

For both pom and pom-ng stability of the resulting kernel is not 
guaranteed.

Netfilter pom (both styles) is just a "collection of patches" to the
Netfilter parts of the Linux kernel. Anything outside submitted (which btw
does not exists in pom-ng) is works in progress or otherwise not deemed
suitable for inclusion in the standard kernel and you should be careful
with what you use from there..  The base class of patches and extensions
is what the netfilter core team viewed as "probably useful for others" and
is what is primarily tested to build properly when there is new releases
of iptables or pom(-ng).


But yes, I agree that set should not be in base until the userspace
dependencies have been resolved. This should be in extra. It would
probably also do good to move userspace components from iptables to 
pom-ng.. (also applies to many other extensions living in both packages)

Regards
Henrik